[llvm-commits] [llvm] r150060 - in /llvm/trunk: include/llvm/IntrinsicsX86.td lib/Target/X86/X86ISelLowering.cpp lib/Target/X86/X86InstrSSE.td

[Duncan Sands]

>     Whether generic IR is a "win" isn't the primary issue here.  The issue
>     is that the user wrote code using intrinsics and expects that exact code
>     to be in the asm.  Whether or not that is the best performing code
>     possible doesn't matter.  It's what they want and we have to respect it.
>     Our customers demand it.
>
>
> Okay. This is a different issue then, and isn't even solved by using intrinsics;
> the optimization passes are absolutely allowed to modify uses of intrinsics. We
> do this in obvious cases for things like memset or ctz, but there is no reason
> the optimization passes won't optimize the llvm.x86 intrinsics too. It's rare,
> but you can see code in ValueTracking.cpp that
> will analyze Intrinsic::x86_sse42_crc32_64_8 for one example,
> ConstantFolding.cpp will fold through x86_sse_cvtss2si for another.

Yeah, this is what I was trying to get at with my "historical essay".  The
compiler will transform intrinsics, and is only going to do this more and
more as time goes on.  If you want a particular asm, use inline asm.  Though
even that is likely to only work for a few years before people start
implementing asm level optimizations (which is sure to be done because it can
be done).

Ciao, Duncan.