<div dir="ltr">On Thu, Jul 14, 2016 at 2:03 PM, Justin Bogner 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><div class="gmail_extra"><div class="gmail_quote"><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">There are a few places in llvm's generic codegen that refer to target<br>
specific intrinsics. This is bad layering and we shouldn't do it. It<br>
also means that if we don't build a target we still have to support all<br>
of it's intrinsics and other such annoyances.<br>
<br>
The main violator of this is InstCombineCalls - I'd like to push this<br>
into the targets, and just have a case that says "if this is target<br>
specific, call into the target specific library". See below for a patch<br>
that starts to go in that direction by making it easier to tell between<br>
generic and target specific intrinsics.<br>
<br>
The other place that this comes up in multiple targets is<br>
AutoUpgrade.cpp, which is kind of special. It probably makes sense to<br>
change these to use intrinsic names instead of IDs - it's probably<br>
overkill to do target specific intrinsic upgrading libraries.<br>
<br>
The rest of the issues are mostly x86 (and a bit of arm and aarch64)<br>
specific code that's scattered about. I think these are mostly just<br>
cutting corners instead of doing the right way, but maybe there are<br>
places here where we need to wire in target hooks.<br></blockquote><div><br></div><div><div>This sounds great!  Its been a wart for a while now.</div></div><div> <br></div><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">
For now I'm considering clang out of scope, but being able to tell which<br>
target an intrinsic is for should also pretty easily clean it up too -<br>
other than a couple of references to ppc.altivec in CGExprScalar and a<br>
strange use of an x86 intrinsic in generic looking EH code, it's all<br>
confined to CGBuiltin.cpp and split up by target anyway.<br></blockquote><div><br></div><div>Aww.  Still a better place than before.</div><div> <br></div><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">
<br>_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org">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/mailman/listinfo/llvm-dev</a><br>
<br></blockquote></div><br>-- <br><div class="gmail_signature" data-smartmail="gmail_signature">Saleem Abdulrasool<br>compnerd (at) compnerd (dot) org</div>
</div></div>