[llvm] r214832 - MachineCombiner Pass for selecting faster instruction

[Jiangning Liu]

Hi Gerolf,

The buildbot at
http://lab.llvm.org:8011/builders/clang-aarch64-lnt/builds/735 is using gcc
4.8.3, but somehow lnt test can all pass. I'm confused around this, because

gcc 4.8.2: fail (I tried)
gcc 4.8.3: pass (Gabor is the maintainer of this buildbot, and he told me
this buildbot is using gcc 4.8.3)
gcc 4.9: fail (You tried)

But they are all on different machines, so it's hard to tell root cause.

Actually, this is not the only gcc issue we encountered so far. We found
another gcc issue causing clang/llvm *release* version failure, and it's
hard to be reproduced with a small test case.

So is it possible to migrate all build bots to clang for all targets in
future?

Thanks,
-Jiangning



2014-08-07 3:37 GMT+08:00 Gerolf Hoflehner <ghoflehner at apple.com>:

> HI Jiangning,
>
> thanks for following up on this. I’m all up for using clang/llvm as the
> build compiler on all bots. :-) Compile time should be much faster, too.
>
> It seems the next steps are:
>
> 1) I’ll work around in the code in the short term, since I expect changing
> the build compiler on all bots will take a while, right?
> 2) I’ll file a bug against gcc so someone has a chance to fix it. Test
> cases for these kind of fails are often hard to come by.
>
> Cheers
> Gerolf
>
>
> On Aug 6, 2014, at 12:35 AM, Jiangning Liu <liujiangning1 at gmail.com>
> wrote:
>
> Hi Gerolf,
>
>
> 2014-08-06 12:19 GMT+08:00 Gerolf Hoflehner <ghoflehner at apple.com>:
>
>> Hi Kevin,
>>
>> I assume you are using gcc as your build compiler? At least in gcc v4.9
>> there seems an issue with the register allocator resulting in a stack
>> overwrite in the target independent part of the machine combiner:
>>
>> MachineCombiner.cpp:
>> /// preservesResourceLen - True when the new instructions do not increase
>> /// resource length
>> ...
>> >>> Allocate ptr to MBB on the stack
>>   ArrayRef<const MachineBasicBlock *> MBBarr(MBB);
>>   unsigned ResLenBeforeCombine = BlockTrace.getResourceLength(MBBarr);
>>
>
> I'm using gcc 4.8.2, and I can reproduce similar issue. I can't find
> source code issue, but for the above two line of source code, I can see gcc
> is generate the following assembly code,
>
> 276                 ArrayRef<const MachineBasicBlock *> MBBarr(MBB);
> 00007ffff5f468c3:   mov -0x1a0(%rbp),%rax
> 00007ffff5f468ca:   mov %rax,-0x160(%rbp)
> 00007ffff5f468d1:   lea -0x160(%rbp),%rdx    *// get the address of the
> 1st argument*
> 00007ffff5f468d8:   lea -0x180(%rbp),%rax
> 00007ffff5f468df:   mov %rdx,%rsi
> 00007ffff5f468e2:   mov %rax,%rdi
> 00007ffff5f468e5:   callq 0x7ffff5f477b8
> <llvm::ArrayRef<llvm::MachineBasicBlock
> const*>::ArrayRef(llvm::MachineBasicBlock const* const&)>     *//
> initialize MBBarr*
> 277                 unsigned ResLenBeforeCombine =
> BlockTrace.getResourceLength(MBBarr);
> 00007ffff5f468ea:   lea -0x160(%rbp),%rax  * // get the address of the
> 2nd argument, but it is overlapped with the 1st one.*
> 00007ffff5f468f1:   mov $0x0,%esi
> 00007ffff5f468f6:   mov %rax,%rdi
> 00007ffff5f468f9:   callq 0x7ffff5e86cf0
> <llvm::ArrayRef<llvm::MCSchedClassDesc const*>::ArrayRef(llvm::NoneType)>
> 00007ffff5f468fe:   lea -0x170(%rbp),%rax   *// get the address of the
> 3rd argument*
> 00007ffff5f46905:   mov $0x0,%esi
> 00007ffff5f4690a:   mov %rax,%rdi
> 00007ffff5f4690d:   callq 0x7ffff5e86cf0
> <llvm::ArrayRef<llvm::MCSchedClassDesc const*>::ArrayRef(llvm::NoneType)>
> 00007ffff5f46912:   mov -0x170(%rbp),%rcx
> 00007ffff5f46919:   mov -0x168(%rbp),%r8
> 00007ffff5f46920:   mov -0x180(%rbp),%rsi
> 00007ffff5f46927:   mov -0x178(%rbp),%r9
> 00007ffff5f4692e:   lea -0x1b0(%rbp),%rdi
> 00007ffff5f46935:   mov -0x160(%rbp),%rax
> 00007ffff5f4693c:   mov -0x158(%rbp),%rdx
> 00007ffff5f46943:   mov %rax,(%rsp)
> 00007ffff5f46947:   mov %rdx,0x8(%rsp)
> 00007ffff5f4694c:   mov %r9,%rdx
> 00007ffff5f4694f:   callq 0x7ffff5df0a60
> <_ZNK4llvm19MachineTraceMetrics5Trace17*getResourceLength*
> ENS_8ArrayRefIPKNS_17MachineBasicBlockEEENS2_IPKNS_16MCSchedClassDescEEESA_ at plt
> >
>
> And here obviously, the address -0x160(%rbp) passed to
> function getResourceLength as the 1st argument is overwritten by the
> initialization code of the 2nd parameter inside the function.
>
> So it looks like a gcc bug. What gcc version are you using in your local
> box? I'm thinking if we should use clang/llvm bootstrap, rather than using
> gcc to build clang/llvm any longer.
>
> Any thoughts?
>
> Thanks,
> -Jiangning
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20140807/44a894cf/attachment.html>