[llvm] r182991 - X86: change MOV64ri64i32 into MOV32ri64

Eric Christopher echristo at gmail.com
Fri May 31 11:27:45 PDT 2013


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.

-eric



More information about the llvm-commits mailing list