[llvm] r182991 - X86: change MOV64ri64i32 into MOV32ri64

David Blaikie dblaikie at gmail.com
Fri May 31 11:35:20 PDT 2013


On Fri, May 31, 2013 at 11:34 AM, David Blaikie <dblaikie at gmail.com> wrote:
> 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'

<fat fingered the wrong key...>

"... our local copy of GDB 7.5's test suite it's only for testing
Clang & I don't think anything about these tests really relates to
Clang's debug info - except maybe some basic line info for inline ASM
which could be tested without the sensitivity to register usage"



More information about the llvm-commits mailing list