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

[David A. Greene]

Nick Lewycky <nlewycky at google.com> writes:

>     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.

That seems like a mistake and is not what I would expect to happen with
intrinsics.  I can understand why compiler developers might want to do
that but some users will be surprised.

We need some way to provide the kind of guarantee I'm talking about.

> Suppose you emit code like this: create your own functions with
> definitions that use the IR implementations, and mark them
> noinline. At the very end, you inline them with a pass that calls
> InlineFunction() directly. Does this preserve the order, or do you
> still have trouble with the backend doing too much reordering?

It's not just reordering.  Instcombine, dagcombine, etc. do a lot of
massaging. 

Again, what is the trouble with keeping intrinsics?  Why rip them out if
people find them useful and necessary?  If the behavior of the optimizer
changes wrt the intrinsics, we can deal with that when it happens.

                                -Dave