<div dir="ltr">Actually there is no miscompile there as esi isn't needed. The flags are which the cmove is using.<div><br></div><div><span style="font-family:arial,sans-serif;font-size:13px">342: shr esi,0x5</span><br style="font-family:arial,sans-serif;font-size:13px">
<span style="font-family:arial,sans-serif;font-size:13px"> 345: lea rbp,[rip+0x0] # 34c <llvm::sys::getHostCPUName()+</span><span style="font-family:arial,sans-serif;font-size:13px">0xbc></span><br style="font-family:arial,sans-serif;font-size:13px">
<span style="font-family:arial,sans-serif;font-size:13px"> 34c: lea r12,[rip+0x0] # 353 <llvm::sys::getHostCPUName()+</span><span style="font-family:arial,sans-serif;font-size:13px">0xc3></span><br style="font-family:arial,sans-serif;font-size:13px">
<span style="font-family:arial,sans-serif;font-size:13px"> 353: cmove rbp,r12 <- this is dependent on the flags from the shift.</span><br></div><div><span style="font-family:arial,sans-serif;font-size:13px"><br></span></div>
<div><span style="font-family:arial,sans-serif;font-size:13px">I think your real problem is that garbage went into ECX instead of 0 and caused cpuid to return 0.</span></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">
On Thu, Sep 12, 2013 at 9:29 PM, Craig Topper <span dir="ltr"><<a href="mailto:craig.topper@gmail.com" target="_blank">craig.topper@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr">Pretty sure you need to check EAX>=7 from cpuid leaf 0 before calling leaf 7 and you need to use the pass ECX=0 to leaf 7. See lib/Target/X86/X86Subtarget.cpp which uses a GetX86CpuIDAndInfoEx function to pass EAX and ECX to cpuid.<div>
<br></div><div>I don't think it explains your compiler bug though.</div></div><div class="gmail_extra"><div><div class="h5"><br><br><div class="gmail_quote">On Thu, Sep 12, 2013 at 2:12 PM, Adam Strzelecki <span dir="ltr"><<a href="mailto:ono@java.pl" target="_blank">ono@java.pl</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>> Anyway, thanks very much for the information. Hopefully that'll let me<br>
> track things down.<br>
<br>
</div>Let me know if you need some more information or dumps.<br>
<div><br>
> Would you mind me taking a day or so to investigate what's going on<br>
> here properly? Introducing a volatile to work around a bug in Clang<br>
> itself just seems perverse to me. (And we shouldn't let a CodeGen bug<br>
> dictate how we implement our functions either).<br>
<br>
</div>Looking at the assembly there's something wrong with SI that is not getting saved anywhere after CPUID and 0x20 bit test before it gets overwritten by LEA.<br>
<br>
332: mov eax,0x7<br>
337: mov rsi,rbx<br>
33a: cpuid<br>
33c: xchg rsi,rbx<br>
33f: and esi,0x20<br>
342: shr esi,0x5<br>
345: lea rbp,[rip+0x0] # 34c <llvm::sys::getHostCPUName()+0xbc><br>
34c: lea r12,[rip+0x0] # 353 <llvm::sys::getHostCPUName()+0xc3><br>
353: cmove rbp,r12<br>
357: lea rdi,[rsp+0x188]<br>
35f: lea rsi,[rip+0x0] # 366 <llvm::sys::getHostCPUName()+0xd6><br>
<br>
In both other cases (2) & (3) SI is saved into stack region.<br>
<div><br>
> I promise I'll do the review of your code after that.<br>
<br>
</div>Thanks.<br>
<br>
Regards,<br>
<span><font color="#888888">--<br>
Adam<br>
</font></span><div><div>_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:LLVMdev@cs.uiuc.edu" target="_blank">LLVMdev@cs.uiuc.edu</a> <a href="http://llvm.cs.uiuc.edu" target="_blank">http://llvm.cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a><br>
</div></div></blockquote></div><br><br clear="all"><div><br></div></div></div><span class="HOEnZb"><font color="#888888">-- <br>~Craig
</font></span></div>
</blockquote></div><br><br clear="all"><div><br></div>-- <br>~Craig
</div>