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

[Sean Silva]

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

>
>
> On Thu, Jul 30, 2015 at 11:27 AM Vedant Kumar <vsk at apple.com> wrote:
>
>> > On Jul 30, 2015, at 10:33 AM, Eric Christopher <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.

-- 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/f26d0144/attachment.html>