[cfe-dev] [PROPOSAL] Reintroduce guards for Intel intrinsic headers

[Eric Christopher]

>
> KBS> ICC considers all intrinsics to be available in any environment,
> regardless of the compiler switches.  So, you can be generating code
> assuming you are targeting a plain old Pentium Processor and use AVX512
> intriniscs (for example).  We specifically choose this model, and consider
> that if such an intrinsic is used, it implies that the user has done the
> necessary checks to ensure that the processor they are running on, supports
> the intrinsics in use in whatever context that happens to be.  And we can
> propogate that “cpu assertion” around a bit in the control-flow-graph. We
> felt this model was necessary to allow code to be developed which did the
> following:
>
>
>
> if (some condition that is only set for a certain processor) {
>
>    // Use processor specific intrinsics to support optimized code for some
> algorithm based on the dynamic check above.
>
> }
>
>
>
> My understanding is that neither gcc nor clang/LLVM really support this
> type of usage.  Because in order to use say an AVX intrinsic,
>
> the whole module that the intrinsic is used in needs to be compiled with
> the compiler switch targeting AVX, potentially allowing AVX instructions
> outside the “safe” area.  Or for some intrinsics (if you get around of
> ifdef guards), you simply will lower them to a set of instructions that
> implements a similar operation, but without using the wider vector the user
> really intended.
>
>
We (recently) and gcc (in 4.4?) moved away from this and more to a method
that you've got. We both do it on a function by function basis rather than
in code blocks.

-eric


>
>
> Kevin B. Smith
>
>
>
> -- Sean Silva
>
>
>
>
>
>
> I'm just not 100% convinced that removing the header guards was necessary
> (which, I admit, could just be due to a lack of understanding on my part).
>
>
>
> Did the above help?
>
>
>
> -eric
>
>
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20150730/7d90dfd8/attachment.html>