<div dir="ltr">Hi Gerolf,<div><br></div><div class="gmail_extra"><br><div class="gmail_quote">2014-08-06 12:19 GMT+08:00 Gerolf Hoflehner <span dir="ltr"><<a href="mailto:ghoflehner@apple.com" target="_blank">ghoflehner@apple.com</a>></span>:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div style="word-wrap:break-word">Hi Kevin,<div><br></div>
<div>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:</div><div>
<br></div><div>MachineCombiner.cpp:</div><div><div style="margin:0px;font-family:Menlo;color:rgb(83,48,225)">/// preservesResourceLen - True when the new instructions do not increase</div><div style="margin:0px;font-family:Menlo;color:rgb(83,48,225)">
/// resource length</div><div style="margin:0px;font-family:Menlo;color:rgb(83,48,225)">...</div><div style="margin:0px;font-family:Menlo;min-height:21px">>>> Allocate ptr to MBB on the stack</div><div style="margin:0px;font-family:Menlo">
  ArrayRef<<span style="color:rgb(52,189,38)">const</span> MachineBasicBlock *> MBBarr(MBB);</div><div style="margin:0px;font-family:Menlo">  <span style="color:rgb(52,189,38)">unsigned</span> ResLenBeforeCombine = BlockTrace.getResourceLength(MBBarr);</div>
</div></div></blockquote><div><br></div><div>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,</div>
<div><br></div><div><div>276                 ArrayRef<const MachineBasicBlock *> MBBarr(MBB);</div><div>00007ffff5f468c3:   mov -0x1a0(%rbp),%rax</div><div>00007ffff5f468ca:   mov %rax,-0x160(%rbp)</div><div>00007ffff5f468d1:   lea -0x160(%rbp),%rdx    <b>// get the address of the 1st argument</b></div>
<div>00007ffff5f468d8:   lea -0x180(%rbp),%rax</div><div>00007ffff5f468df:   mov %rdx,%rsi</div><div>00007ffff5f468e2:   mov %rax,%rdi</div><div>00007ffff5f468e5:   callq 0x7ffff5f477b8 <llvm::ArrayRef<llvm::MachineBasicBlock const*>::ArrayRef(llvm::MachineBasicBlock const* const&)>     <b>// initialize MBBarr</b></div>
<div>277                 unsigned ResLenBeforeCombine = BlockTrace.getResourceLength(MBBarr);</div><div>00007ffff5f468ea:   lea -0x160(%rbp),%rax  <b> // get the address of the 2nd argument, but it is overlapped with the 1st one.</b></div>
<div>00007ffff5f468f1:   mov $0x0,%esi</div><div>00007ffff5f468f6:   mov %rax,%rdi</div><div>00007ffff5f468f9:   callq 0x7ffff5e86cf0 <llvm::ArrayRef<llvm::MCSchedClassDesc const*>::ArrayRef(llvm::NoneType)></div>
<div>00007ffff5f468fe:   lea -0x170(%rbp),%rax   <b>// get the address of the 3rd argument</b></div><div>00007ffff5f46905:   mov $0x0,%esi</div><div>00007ffff5f4690a:   mov %rax,%rdi</div><div>00007ffff5f4690d:   callq 0x7ffff5e86cf0 <llvm::ArrayRef<llvm::MCSchedClassDesc const*>::ArrayRef(llvm::NoneType)></div>
<div>00007ffff5f46912:   mov -0x170(%rbp),%rcx</div><div>00007ffff5f46919:   mov -0x168(%rbp),%r8</div><div>00007ffff5f46920:   mov -0x180(%rbp),%rsi</div><div>00007ffff5f46927:   mov -0x178(%rbp),%r9</div><div>00007ffff5f4692e:   lea -0x1b0(%rbp),%rdi</div>
<div>00007ffff5f46935:   mov -0x160(%rbp),%rax</div><div>00007ffff5f4693c:   mov -0x158(%rbp),%rdx</div><div>00007ffff5f46943:   mov %rax,(%rsp)</div><div>00007ffff5f46947:   mov %rdx,0x8(%rsp)</div><div>00007ffff5f4694c:   mov %r9,%rdx</div>
<div>00007ffff5f4694f:   callq 0x7ffff5df0a60 <_ZNK4llvm19MachineTraceMetrics5Trace17<b>getResourceLength</b>ENS_8ArrayRefIPKNS_17MachineBasicBlockEEENS2_IPKNS_16MCSchedClassDescEEESA_@plt></div></div><div><br></div>
<div>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. <br></div><div><br></div><div>
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.</div><div><br></div><div>Any thoughts?<br>
</div><div><br></div><div>Thanks,</div><div>-Jiangning</div></div></div></div>