Hi,
I was tracking the issue discussed earlier, and I was wondering if a bug for the missed optimizations, was ever filed, and if it has been fixed since? If so in which llvm version, and more specifically which optimization pass.
http://lists.cs.uiuc.edu/pipermail/llvmdev/2010-January/028877.html
Thanks,
Regards,
Arushi
clang has been fixed to generate code which is generally more friendly
to the optimizers for situations like that.
-Eli
Hi Arushi,
I was tracking the issue discussed earlier, and I was wondering if a bug for the
missed optimizations, was ever filed, and if it has been fixed since? If so in
which llvm version, and more specifically which optimization pass.http://lists.cs.uiuc.edu/pipermail/llvmdev/2010-January/028877.html
this doesn't really sound like an LLVM optimizer issue, it looks more like an
issue with the llvm-g++ front-end to LLVM. In order to conform to the platform
ABI (x86-64 in this case), the front-end has to carefully arrange how parameters
are passed to functions and return values handled. This can result in nasty
code that picks parameters apart and puts one bit in a float, another in an
int etc. It's often hard for the optimizers to do much about this - so the
front-end needs to carefully do things in such a way as to help the optimizers
as much as possible while maintaining ABI conformance. I don't think this will
ever be improved in llvm-g++ (which is now deprecated). Hopefully clang does a
better job. I plan to rewrite the ABI stuff completely in dragonegg, so it may
end up being fixed there one day.
Ciao, Duncan.
When I wrote some ABI stuff for LDC, I noticed that a double is passed
the same way as <2 x float> on x86-64. My guess is that if what you're
passing is actually two floats instead of a double (and even if you're
passing a union that might be either) then passing it as <2 x float>
would result in much nicer code since LLVM should be able to figure
out how to take vectors apart if that's needed (or how to bitcast if
you want the double member of the union).