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

[Smith, Kevin B]

From: cfe-dev-bounces at cs.uiuc.edu [mailto:cfe-dev-bounces at cs.uiuc.edu] On Behalf Of Sean Silva
Sent: Thursday, July 30, 2015 12:02 PM
To: Eric Christopher
Cc: Vedant Kumar; Clang
Subject: Re: [cfe-dev] [PROPOSAL] Reintroduce guards for Intel intrinsic headers



On Thu, Jul 30, 2015 at 11:33 AM, Eric Christopher <echristo at gmail.com<mailto:echristo at gmail.com>> wrote:

On Thu, Jul 30, 2015 at 11:27 AM Vedant Kumar <vsk at apple.com<mailto:vsk at apple.com>> wrote:
> On Jul 30, 2015, at 10:33 AM, Eric Christopher <echristo at gmail.com<mailto:echristo at gmail.com>> wrote:
>
>> I don't see any downsides to reintroducing these guards.
>
> Then you weren't really paying attention to the point of removing them :)
>
> The idea is so that the headers can be used, with appropriate target attributes, for any code.

Right, I thought about this but wasn't sure if there were benefits to having symbols available for an unsupported target.

I.e, is there some reason a project might want to include the header for SSE4 intrinsics if it can't use any of those symbols?

I put a code snippet for something to do in the commit, but the general idea is that you can compile a function for a specific target with subtarget features and use the target attribute to add subtarget features and you'll want to be able to use the intrinsics at the same time. It won't work if you block them at the preprocessor level.


Sorry if this is a stupid question, but would it make sense to gate this behind a flag? Breaking user code is bad, bad news. This target attribute stuff is pretty niche, so it would make sense to have it be opt-in.

Or is this how GCC/ICC have always done it? I would expect user code to not be breaking if that were the case though.

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.

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<mailto: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/e6ffde85/attachment.html>