[llvm-dev] Let's stop using target specific intrinsics in generic code

[Jim Grosbach via llvm-dev]

Yes, yes, a thousand times yes. Please do this.

-Jim

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