[llvm-commits] [llvm] r66366 - in /llvm/trunk: lib/Transforms/Scalar/ScalarReplAggregates.cpp test/Transforms/ScalarRepl/2008-06-22-LargeArray.ll test/Transforms/ScalarRepl/vector_memcpy.ll

[Chris Lattner]

On Mar 9, 2009, at 1:31 PM, Dale Johannesen wrote:

>> Ok, this is pretty insane, and I'm sure that there are cases where
>> SROA would get this "wrong" before too.  I think that the only
>> reasonable course of action is to make the IR well defined w.r.t.  
>> load
>> and store and treat this as an x86 backend bug.  Note that this has
>> already been recognized to be a real performance issue (PR3560) as
>> well.
>
> By the time the x86 backend sees this it looks exactly like a floating
> point load and store in the source.   It should be possible for the
> x86 backend to detect that (load whose only use is in a store) and
> turn it back into int loads and stores, but it seems like a bad
> approach.  The x87 behavior is IEEE754 conformant AFAICT so the same
> problem exists on other targets, at least theoretically, and you would
> lose in the rare case where somebody wrote a float load and store and
> actually wanted the exception to go off.

I'm not talking about theoretical IEEE here, I'm talking about what  
semantics we want for LLVM IR.  I think that load/store pairs should  
always be value-preserving.  Do you disagree?

-Chris