llvm dev - Sep 2010 - [LLVMdev] "equivalent" .ll files diverge after optimizations are applied

On Aug 31, 2010, at 10:19 PM, Chris Lattner wrote:
> 
> Hi Argiris,
> 
> The real problem here is that the X86 backend is turning datatypes like
<1 x i64> into MMX operations, but doesn't do so in a safe way
(it's not inserting the requisite EMMS instructions).  After discussing this
with Dale and Bill, the right fix is to stop mapping generic vectors onto MMX
operations.  This will define away the existing -disable-mmx flag and make stuff
like this impossible.
> 
> However, this isn't going to happen in the next couple days, certainly
not in time for the 2.8 release branch on friday.  As such, I checked in a
horrible hack in r112696 that prevents SRoA from introducing mmx specific vector
types.  I'm not aware of a target where those datatypes are actually useful,
so this shouldn't be bad.  On your testcase, no mmx operations are produced.
Those types are all used with NEON.  I'll try to do some experiments to
measure the impact of this....

On Sep 1, 2010, at 9:43 AM, Bob Wilson wrote:
> 
> On Aug 31, 2010, at 10:19 PM, Chris Lattner wrote:
>> 
>> Hi Argiris,
>> 
>> The real problem here is that the X86 backend is turning datatypes like
<1 x i64> into MMX operations, but doesn't do so in a safe way
(it's not inserting the requisite EMMS instructions).  After discussing this
with Dale and Bill, the right fix is to stop mapping generic vectors onto MMX
operations.  This will define away the existing -disable-mmx flag and make stuff
like this impossible.
>> 
>> However, this isn't going to happen in the next couple days,
certainly not in time for the 2.8 release branch on friday.  As such, I checked
in a horrible hack in r112696 that prevents SRoA from introducing mmx specific
vector types.  I'm not aware of a target where those datatypes are actually
useful, so this shouldn't be bad.  On your testcase, no mmx operations are
produced.
> 
> Those types are all used with NEON.  I'll try to do some experiments to
measure the impact of this....
If it matters, I can conditionalize the hack on the target triple being
i386/x86-64.  Just let me know.

-Chris

On Sep 1, 2010, at 12:27 PM, Chris Lattner wrote:
> 
> On Sep 1, 2010, at 9:43 AM, Bob Wilson wrote:
> 
>> 
>> On Aug 31, 2010, at 10:19 PM, Chris Lattner wrote:
>>> 
>>> Hi Argiris,
>>> 
>>> The real problem here is that the X86 backend is turning datatypes
like <1 x i64> into MMX operations, but doesn't do so in a safe way
(it's not inserting the requisite EMMS instructions).  After discussing this
with Dale and Bill, the right fix is to stop mapping generic vectors onto MMX
operations.  This will define away the existing -disable-mmx flag and make stuff
like this impossible.
>>> 
>>> However, this isn't going to happen in the next couple days,
certainly not in time for the 2.8 release branch on friday.  As such, I checked
in a horrible hack in r112696 that prevents SRoA from introducing mmx specific
vector types.  I'm not aware of a target where those datatypes are actually
useful, so this shouldn't be bad.  On your testcase, no mmx operations are
produced.
>> 
>> Those types are all used with NEON.  I'll try to do some
experiments to measure the impact of this....
> 
> If it matters, I can conditionalize the hack on the target triple being
i386/x86-64.  Just let me know.
Some simple test programs look fine.

It also turns out that my nightly tester picked up this change last night.  I
didn't see any obvious problems there except for a 13.5% regression on one
internal test (<rdar://problem/8383253>) but that regression still
reproduces with this change reverted.  I sure don't want that hack to stick
around for long, but as long as it gets removed soon, I guess we're fine for
now.