llvm dev - Mar 2011 - [LLVMdev] 64 bit MRV problem; Missed optimizations.

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20110307/2be61c20/attachment.html>

On Mon, Mar 7, 2011 at 1:51 PM, Arushi Aggarwal <arushi987 at gmail.com>
wrote:
> 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
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.

On Tue, Mar 8, 2011 at 8:37 AM, Duncan Sands <baldrick at free.fr>
wrote:
>> 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.
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).