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

[Hal Finkel]

On Thu, 2012-02-09 at 10:51 -1000, Chandler Carruth wrote:
> I think the primary problem here are the many definitions and
> understandings of what 'intrinsics' mean.
> 
> 
> To be clear, I think most of the LLVM developers have been operating
> under the following assumption: intrinsics are a library-means of
> expressing operations very useful or common on a particular system
> which have no in-language formulation. As such, they are just a
> language extension with defined and specified semantics. The compiler
> is then free to interpret them, lower them, optimize, and even delete
> them according to the as-if rules. I think that's fundamentally the
> *right* model, as there is no alternative. If you want to express
> operations on SSE vectors, but would like the compiler to have all of
> its usual freedom, what else can you use besides intrinsics?

There is an alternate view which says: intrinsics form an embedded
domain-specific language within C/C++ which allows programming assembly
while letting the compiler take care of scheduling and register
allocation. In order words, it is a method for doing user-specified
instruction selection when the compiler's built-in abilities in this
area are lacking (while letting the compiler do other things that it is
good at doing).

In general, I don't know of anyone who minds their intrinsics being
constant folded, etc. so long as doing so never hurts performance (and
this is important for some use cases like when intrinsics are used as
part of C++ expression template libraries for matrix operations). On the
other hand, doing things that can perform worse, or using completely
different instruction, is another matter.

 -Hal

> 
> 
> However...
> 
> On Thu, Feb 9, 2012 at 10:41 AM, David A. Greene <dag at cray.com> wrote:
>         We absolutely need some way to tell LLVM, "leave this alone."
>          It goes
>         beyond intrinsics even.
> 
> 
> This is a very reasonable requirement, and I actually think LLVM has
> exactly the means to deal with it: *volatile* inline asm. This says to
> the compiler, explicitly and without ambiguity, "leave this alone". It
> must not be changed, it must be preserved at all costs.
> 
> 
> I think anything short of volatile inline asm is subject to as-if, and
> merely a matter of time before the compiler begins optimizing even
> these sequences.
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits

-- 
Hal Finkel
Postdoctoral Appointee
Leadership Computing Facility
Argonne National Laboratory