[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

[Dale Johannesen]

On Mar 9, 2009, at 1:36 PMPDT, Chris Lattner wrote:

>
> 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?

No, that is not what the semantics are when you write

    f1 = f2;

How else would you represent this?