[llvm] r182991 - X86: change MOV64ri64i32 into MOV32ri64

[David Blaikie]

On Fri, May 31, 2013 at 11:27 AM, Eric Christopher <echristo at gmail.com> wrote:
> On Fri, May 31, 2013 at 11:20 AM, David Blaikie <dblaikie at gmail.com> wrote:
>> On Fri, May 31, 2013 at 5:14 AM, Tim Northover <t.p.northover at gmail.com> wrote:
>>>> X86: change MOV64ri64i32 into MOV32ri64
>>>
>>> Hmm, it seems this broke the gdb 7.5 bot:
>>> http://lab.llvm.org:8011/builders/clang-x86_64-ubuntu-gdb-75/builds/5399.
>>>
>>> It looks like the test itself is dodgy: it consists of a few inline
>>> asm blocks, marked to clobber %eax and so on. However, it expects the
>>> compiler won't use those registers in *between* either. Previously
>>> this was true, but now on -O0 instead of:
>>>     movl $data, %r9d
>>> we produce:
>>>     movl $data, %eax
>>>     movl %eax, %r9d
>>>
>>> The extra instruction goes away (as it should) at higher
>>> optimisations, and I think it's perfectly valid, but the test doesn't
>>> like it.
>>>
>>> Can we XFAIL individual tests on this gdb7.5 bot, or do we usually do
>>> something else? I can't believe this hasn't come up before.
>>
>> As you can see in the tests, this has come up before (these were
>> failing already when I started running the GDB 7.5 test suite against
>> Clang) - the xfails marked with "test is oversensitive to register
>> allocation/unoptimized code" represented the previous failures.
>>
>> In light of this new change I've just given up & marked the tests as
>> not to be run at all (r183027).
>>
>> If someone wants to argue that we should be preserving those registers
>> - I'm all ears & I can update the tests (though this probably
>> shouldn't be tested by our debug info tests anyway - we should have
>> other tests for it) & remember, this invariant was already not held,
>> just to a lesser degree of breakage - so we'd want to consider going
>> back & fixing that too.
>
> I'm good with this change. We should probably try to change the tests
> in such a way that they continue to test and also won't break due to
> this understandable invariant, but that's a problem for another day.

Yeah, I'm not sure if/how to do that - but it'll be relevant if/when
we want to run Clang against ToT GDB's real test suite. For now with
our local copy of GDB 7.5'

>
> -eric