[llvm] r214832 - MachineCombiner Pass for selecting faster instruction

[Jiangning Liu]

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/20140806/65abb9c6/attachment.html>