
<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div></div><div>Thank you, will try that and dig into the code as well :)</div><div><br>On 8 May 2017, at 18:20, Craig Topper <<a href="mailto:craig.topper@gmail.com">craig.topper@gmail.com</a>> wrote:<br><br></div><blockquote type="cite"><div><div dir="ltr">getProcessTriple just determines operation system, and architecture. It doesn't deal with specific instruction set features. The CPU should be controlled by MCPU on the EngineBuilder i think. The CPU autodetection code lives in getHostCPUName in lib/Support/Host.cpp, but I don't think the JIT calls into. I think its expected the user would call it or pass a specific CPU string to the MCPU for the EngineBuilder. But getHostCPUName in LLVM 3.5 doesn't recognize Kabylake or Skylake.<div><br></div><div>The Cannot select: means that an intrinsic was used but no pattern could be found in lib/Target/X86/X86GenDAGISel.inc that applies to the enabled feature set. We have separate patterns for that intrinsic for at least SSE4.1 and AVX1 in 3.5. So that implies that the EngineBuilder thinks your CPU doesn't support SSE4.1 or AVX1 either. But I'm not sure why you would be getting different behavior on Kabylake.</div><div><br></div><div>Can you try setting EngineBuilder's MCPU to "<span style="color:rgb(186,33,33);font-family:monospace;font-size:medium;white-space:pre">core-avx2"?</span></div></div><div class="gmail_extra"><br clear="all"><div><div class="gmail_signature" data-smartmail="gmail_signature">~Craig</div></div>

<br><div class="gmail_quote">On Mon, May 8, 2017 at 10:06 AM, Andy Schneider <span dir="ltr"><<a href="mailto:andy@schnoberts.com" target="_blank">andy@schnoberts.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="auto"><div></div><div>Correction: getProcessTriple not getProcessTarget.</div><div><div class="h5"><div><br>On 8 May 2017, at 17:55, Andy Schneider via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>> wrote:<br><br></div><blockquote type="cite"><div><div></div><div>Thank you. I'm letting it auto detect by setting the target using getProcessTarget. I disabled avx512 support by passing -avx512f (and the other variants) to setMAttrs on EngineBuilder. I can see refs to avx512 in X86.td. It's the exact same executable running on Kabylake. </div><div><br></div><div>What does the Cannot select: specifically mean? Is there some table that doesn't have a definition for a key in it that I would need to patch up?</div><div><br></div><div>Am I answering your questions?</div><div><br></div><div><br>On 8 May 2017, at 17:32, Craig Topper <<a href="mailto:craig.topper@gmail.com" target="_blank">craig.topper@gmail.com</a>> wrote:<br><br></div><blockquote type="cite"><div><div dir="ltr">I can try to help.<div><br></div><div>Are you passing a CPU string or are you letting it autodetect the CPU using getHostCPUName? I don't see support detecting skylake or even avx-512 support in the autodetection code that far back. Are you doing the same thing for the i7 kabylake? How did you disable AVX-512 code gen? </div></div><div class="gmail_extra"><br clear="all"><div><div class="m_8367558309618899613gmail_signature" data-smartmail="gmail_signature">~Craig</div></div>

<br><div class="gmail_quote">On Mon, May 8, 2017 at 9:21 AM, Andy Schneider via llvm-dev <span dir="ltr"><<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br>

<br>

I have a JIT compiler using the legacy JIT on LLVM 3.5 that, when run on the Xeon v5 Skylakes produces "Cannot select: intrinsic %<a href="http://llvm.x86.sse41.round.sd" rel="noreferrer" target="_blank">llvm.x86.sse41.round.sd</a>". Note, this does not occur on i7 Kabylakes. To get this far I had to disable AVX512 code gen.<br>

<br>

Upgrading the system I am looking at from 3.5 to a later version is a big job that I'd prefer not to have on my critical path.<br>

<br>

Does anyone have any tips on where I would look to debug this sort of issue? I'm new to LLVM.<br>

<br>

Thanks<br>

<br>

Andy<br>

______________________________<wbr>_________________<br>

LLVM Developers mailing list<br>

<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>

<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/<wbr>mailman/listinfo/llvm-dev</a><br>

</blockquote></div><br></div>

</div></blockquote></div></blockquote><blockquote type="cite"><div><span>______________________________<wbr>_________________</span><br><span>LLVM Developers mailing list</span><br><span><a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a></span><br><span><a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" target="_blank">http://lists.llvm.org/cgi-bin/<wbr>mailman/listinfo/llvm-dev</a></span><br></div></blockquote></div></div></div></blockquote></div><br></div>

</div></blockquote></body></html>