The following seemingly identical functions, get compiled to quite
different machine code. The first is correctly optimized (the
computation of var y is nicely moved into the else branch of the "if"
statement), which the second one is not (the full computation of var y
is always done). The output was produced using the demo page on
llvm's web site (optimization level LTO).
Can someone shed some light on this strange behavior?
Thanks,
Brent
The IR you're seeing is the IR we naturally generate for the given IR,
and LLVM doesn't have an optimization to turn your f2 into f1. Which
version is better depends on the values passed into the function,
which makes it a bit tricky to write an optimization to turn one into
the other.
-Eli
Hi folks,
I'm interested in building a secure and verifiable operating system. One good way to do it is to build the OS with high level language, such as Java or C# since verification is significantly easier.
I have some experience on analyzing LLVM byte codes, so I also plan to compile everything into LLVM byte codes to analyze and verify my OS.
However, I also plan to write my own runtime, since I don't want to rely on GC (I'm considering something like region-based memory management).
My question is what's the status of high level language support in LLVM?
To my best knowledge, (1) there's a java class to llvm byte code translator in the SVN. (2) the VMKit project claims that it has a good JVM.
I appreciate if you could give me some more information. Comments and suggestions are also appreciated.
Thanks!
~Haohui
The question isn't really clear. What features are you looking for?
-Eli
I don't understand your point. Which version is better does NOT
depend on what inputs are passed to the function. The compiled code
for (as per llvm) f1 will always take less time to execute than f2.
for x > 0 => T(f1) < T(f2)
for x <= 0 => T(f1) = T(f2)
where T() is the time to execute the given function.
So always T(f1) <= T(f2).
I would call this a missed optimization opportunity. I think it
warrants a bug report.
If I do the same experiment with gcc I get identical code for the two functions:
Apologies for the formatting but you get the point.
Neo
I don't understand your point. Which version is better does NOT
depend on what inputs are passed to the function. The compiled code
for (as per llvm) f1 will always take less time to execute than f2.for x > 0 => T(f1) < T(f2)
for x <= 0 => T(f1) = T(f2)where T() is the time to execute the given function.
So always T(f1) <= T(f2).
You're not taking branch prediction into account. Given the cost of
the multiplies, it probably doesn't matter so much for your testcase,
but we still need a cost model.
I would call this a missed optimization opportunity. I think it
warrants a bug report.
Sure.
-Eli