[llvm] r214832 - MachineCombiner Pass for selecting faster instruction

[Gerolf Hoflehner]

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 <_ZNK4llvm19MachineTraceMetrics5Trace17getResourceLengthENS_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/20140806/a1d6b0ea/attachment.html>