Skip to content

[ConstantFold] Fold log1p and log1pf when the input parameter is a constant value. #112113

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 6 commits into from
Oct 15, 2024
Merged
Show file tree
Hide file tree
Changes from 2 commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
8 changes: 7 additions & 1 deletion llvm/lib/Analysis/ConstantFolding.cpp
Original file line number Diff line number Diff line change
Expand Up @@ -1679,7 +1679,8 @@ bool llvm::canConstantFoldCallTo(const CallBase *Call, const Function *F) {
case 'l':
return Name == "log" || Name == "logf" || Name == "logl" ||
Name == "log2" || Name == "log2f" || Name == "log10" ||
Name == "log10f" || Name == "logb" || Name == "logbf";
Name == "log10f" || Name == "logb" || Name == "logbf" ||
Name == "log1p" || Name == "log1pf";
case 'n':
return Name == "nearbyint" || Name == "nearbyintf";
case 'p':
Expand Down Expand Up @@ -2394,6 +2395,11 @@ static Constant *ConstantFoldScalarCall1(StringRef Name,
if (!APF.isZero() && TLI->has(Func))
return ConstantFoldFP(logb, APF, Ty);
break;
case LibFunc_log1p:
case LibFunc_log1pf:
if (APF > APFloat(APF.getSemantics(), "-1") && TLI->has(Func))
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Avoid the string? Also still fold if call is memory none

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Using -1 directly seems to pick a different constructor and not achieve the intended behavior. Using -1.0 will pick a deleted constructor, so I opted to use "-1" here.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There is an APFloat::getOne constructor

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I tried this as well, but it still doesn't work. It seems really strange.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What do you mean doesn't work?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So APFloat bug, cool

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

cc @davemgreen Can you have a look and add some unittests?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I will fix this.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fixed. Please rebase this patch on a54d88f.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done.

return ConstantFoldFP(log1p, APF, Ty);
break;
case LibFunc_logl:
return nullptr;
case LibFunc_nearbyint:
Expand Down
113 changes: 113 additions & 0 deletions llvm/test/Transforms/InstCombine/log1p.ll
Original file line number Diff line number Diff line change
@@ -0,0 +1,113 @@
; NOTE: Assertions have been autogenerated by utils/update_test_checks.py UTC_ARGS: --version 5
; RUN: opt < %s -passes=instcombine -S | FileCheck %s

define float @log1pf_const() {
; CHECK-LABEL: define float @log1pf_const() {
; CHECK-NEXT: [[R:%.*]] = call float @log1pf(float 7.000000e+00)
; CHECK-NEXT: ret float 0x4000A2B240000000
;
%r = call float @log1pf(float 7.000000e+00)
ret float %r
}

define double @log1p_const() {
; CHECK-LABEL: define double @log1p_const() {
; CHECK-NEXT: [[R:%.*]] = call double @log1p(double 7.000000e+00)
; CHECK-NEXT: ret double 0x4000A2B23F3BAB73
;
%r = call double @log1p(double 7.000000e+00)
ret double %r
}

define float @log1pf_minus_one() {
; CHECK-LABEL: define float @log1pf_minus_one() {
; CHECK-NEXT: [[R:%.*]] = call float @log1pf(float -1.000000e+00)
; CHECK-NEXT: ret float [[R]]
;
%r = call float @log1pf(float -1.000000e+00)
ret float %r
}

define double @log1p_minus_one() {
; CHECK-LABEL: define double @log1p_minus_one() {
; CHECK-NEXT: [[R:%.*]] = call double @log1p(double -1.000000e+00)
; CHECK-NEXT: ret double [[R]]
;
%r = call double @log1p(double -1.000000e+00)
ret double %r
}

define float @log1pf_zero() {
; CHECK-LABEL: define float @log1pf_zero() {
; CHECK-NEXT: [[R:%.*]] = call float @log1pf(float 0.000000e+00)
; CHECK-NEXT: ret float 0.000000e+00
;
%r = call float @log1pf(float 0.000000e+00)
ret float %r
}

define double @log1p_zero() {
; CHECK-LABEL: define double @log1p_zero() {
; CHECK-NEXT: [[R:%.*]] = call double @log1p(double 0.000000e+00)
; CHECK-NEXT: ret double 0.000000e+00
;
%r = call double @log1p(double 0.000000e+00)
ret double %r
}

define float @log1pf_inf() {
; CHECK-LABEL: define float @log1pf_inf() {
; CHECK-NEXT: [[R:%.*]] = call float @log1pf(float 0x7FF0000000000000)
; CHECK-NEXT: ret float [[R]]
;
%r = call float @log1pf(float 0x7FF0000000000000)
ret float %r
}

define double @log1p_inf() {
; CHECK-LABEL: define double @log1p_inf() {
; CHECK-NEXT: [[R:%.*]] = call double @log1p(double 0x7FF0000000000000)
; CHECK-NEXT: ret double [[R]]
;
%r = call double @log1p(double 0x7FF0000000000000)
ret double %r
}

define float @log1pf_nan() {
; CHECK-LABEL: define float @log1pf_nan() {
; CHECK-NEXT: [[R:%.*]] = call float @log1pf(float 0x7FF8000000000000)
; CHECK-NEXT: ret float [[R]]
;
%r = call float @log1pf(float 0x7FF8000000000000)
ret float %r
}

define double @log1p_nan() {
; CHECK-LABEL: define double @log1p_nan() {
; CHECK-NEXT: [[R:%.*]] = call double @log1p(double 0x7FF8000000000000)
; CHECK-NEXT: ret double [[R]]
;
%r = call double @log1p(double 0x7FF8000000000000)
ret double %r
}

define float @log1pf_poison() {
; CHECK-LABEL: define float @log1pf_poison() {
; CHECK-NEXT: [[R:%.*]] = call float @log1pf(float poison)
; CHECK-NEXT: ret float [[R]]
;
%r = call float @log1pf(float poison)
ret float %r
}

define double @log1p_poison() {
; CHECK-LABEL: define double @log1p_poison() {
; CHECK-NEXT: [[R:%.*]] = call double @log1p(double poison)
; CHECK-NEXT: ret double [[R]]
;
%r = call double @log1p(double poison)
ret double %r
}

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Test memory none special cases

Copy link
Contributor Author

@c8ef c8ef Oct 13, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I have indeed considered handling memory(none) cases. My current plan is not to handle libc functions on a case-by-case basis, but to directly use the value from the libc function regardless of its parameter. Essentially, what I want is to pass the CallBase into the constantFold function, which involves two scenarios. In Case 1, if there are no floating-point exceptions, everything is fine, and we return the folded value. In Case 2, if there is a floating-point exception, we return either nullptr or the exact value returned from the function (such as NaN, HUGE_VAL, etc.) depending on whether this call accesses memory. By doing this, we can eliminate the range check in the Constant Folding phase and avoid error handling based on each function. I look forward to hearing your thoughts on this initial plan.

Constant *ConstantFoldFP(double (*NativeFP)(double), const APFloat &V, Type *Ty,
                         CallBase *CB) {
  llvm_fenv_clearexcept();
  double Result = NativeFP(V.convertToDouble());
  if (llvm_fenv_testexcept()) {
    llvm_fenv_clearexcept();

    if (CB->doesNotAccessMemory())
      return GetConstantFoldFPValue(Result, Ty);
    else
      return nullptr;
  }

  return GetConstantFoldFPValue(Result, Ty);
}

Handling memory(none) cases will impact all current folding operations. I believe it may break some tests and require additional testing. Therefore, my preference is to constant fold most common math functions as much as possible, and then address edge cases afterwards. Would this approach be acceptable?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think the consideration of doesNotAccessMemory belongs down in ConstantFoldFP. It should produce the constant folded value regardless of the side effects. The legality of ignoring the side effects is context dependent

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Plus you can and should still add the tests for these cases here, even if they do not fold yet

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Plus you can and should still add the tests for these cases here, even if they do not fold yet

Done.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think the consideration of doesNotAccessMemory belongs down in ConstantFoldFP. It should produce the constant folded value regardless of the side effects. The legality of ignoring the side effects is context dependent

But IIUC the current implementation of ConstantFoldFP already considers side effects? If errno is set or a floating-point exception occurs, it returns nullptr instead of the expected return value.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would consider that a defect of implementation. The separation of concerns should yield the result. If we wanted, we could produce a side piece of information for raised errors. Whether or not you care if an error occurred depend on the callsite (i.e we can ignore any exceptions in default FP environment, and memory(none) callsites can ignore errno writes)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I believe our ideas align. Even if the implementation of ConstantFolfFP directly returns the result from the underlying libc, we still need a wrapper to validate the libc function parameter. Utilizing fp exceptions and errno to determine the legitimacy of the parameter is convenient as it eliminates the need to write range checks for each individual function.

declare float @log1pf(float)
declare double @log1p(double)
Loading