constant folding for standard math functions

By the way:

x * 1 = 1
is one optimisation I never want to see in llvm please.

By the way:

x * 1 = 1
is one optimisation I never want to see in llvm please.

Did you mean x * 1 = x, or were you making a joke? (:

Rob

What about the well-known simplification

     log(x) = 10?

(Sorry, it's an order-of-magnitude physics joke.)

7x57

sorry forgot to change address :confused:
Rob:

from original post:

I would expect the following optimizations, but didn’t find them in the
code:
x + 0 = x
x * 0 = 0
x * 1 = 1
x * -1 = -x

Take a look at lib/Analysis/InstructionSimplify.cpp

-Chris

Hi Jochen,

I just wanted to point out that if x = inf the result of x * 0 is in indeterminate form so reducing it to zero would give the wrong result in that case.

Thanks,
Javier

I just wanted to point out that if x = inf the result of x * 0 is in indeterminate form so reducing it to zero would give the wrong result in that case.

Yes, thanks for the hint, but someone else already pointed out that nan*0 is also not 0.

I have a special application where inf and nan will not occur, therefore I will patch
my local llvm to optimize floats more aggressively.
If the result of 2.0 * 2.0 is between 3.9 and 4.1 this is sufficient for me if it's faster :wink:

-Jochen

Hi!

I have a new idea:

why not make a difference between null and 0.0 and x * null is null.
null is of course only a compile time constant that can be used to
remove unused parts of floating point computations, i.e. all
inputs to a floating point computation that are not used can
be set to null before compiling it.

-Jochen

Hi!

I wonder if llvm::APFloat::toString() can be const since
it should not modify the APFloat.

-Jochen

Done in r97883, thanks.

Ooh, that would be very cool. :slight_smile:

Note that your optimizations also fail on other values such as -0.0 and not
just infinity and NaN.

Hi!

I'd like to find the point where the control flow joins after a branch.

e.g. if I have the following function

if (a < b)
    foo1();
else
    foo2();
bar();

Then the control flow splits at the basic block containing a < b with
a branch as terminator instruction. At the basic block with bar() the control
flow joins again (at first my control flow graph does not have loops).

I would think I have to calculate the post dominator tree and then call
findNearestCommonDominator on the two branches, but this function
is missing. Does this have a reason? I would think it's just

inline BasicBlock *findNearestCommonDominator(BasicBlock *A, BasicBlock *B) {
    return DT->findNearestCommonDominator(A, B);
  }

like for llvm::DominatorTree. Is it possible to add it?

The method of finding the control flow join should also work for this case:

if (a < b)
{
    foo1();
    if (c < d) goto label;
    foo2();
}
else
{
    foo3();
label:
    foo4();
}
bar();

- Jochen

Hi!

Hi Jochen,

I'd like to find the point where the control flow joins after a branch.

e.g. if I have the following function

if (a< b)
     foo1();
else
     foo2();
bar();

Then the control flow splits at the basic block containing a< b with
a branch as terminator instruction. At the basic block with bar() the
control
flow joins again (at first my control flow graph does not have loops).

I would think I have to calculate the post dominator tree and then call
findNearestCommonDominator on the two branches, but this function
is missing. Does this have a reason? I would think it's just

inline BasicBlock *findNearestCommonDominator(BasicBlock *A, BasicBlock
*B) {
     return DT->findNearestCommonDominator(A, B);
   }

like for llvm::DominatorTree. Is it possible to add it?

It was probably just not added, as the PostDominatorTree is not used a lot at the moment.

I added it. It is a trivial change.
http://llvm.org/viewvc/llvm-project?rev=97915&view=rev

It should just work, as the code paths are the same for both Dominator and PostDominatorTree in this case.

In general the PostDominatorTree works well. I use it for the RegionInfo pass and it works flawless, but I think there may still be some bugs in cases with infinite loops. If this is the case please report back. They should be fixed anyways, as they are probably general PostDominatorTree bugs and not especially related to the findNearestCommonDominator() function.

The method of finding the control flow join should also work for this case:

Yes.

if (a< b)
{
     foo1();
     if (c< d) goto label;
     foo2();
}
else
{
     foo3();
label:
     foo4();
}
bar();

- Jochen

Tobi