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

[Justin Bogner via llvm-dev]

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.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: intrinsics-generic-v-target.patch
Type: text/x-patch
Size: 13086 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160714/2c444164/attachment.bin>