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

[Eric Christopher]

On Thu, Jul 30, 2015 at 12:02 PM Sean Silva <chisophugis at gmail.com> wrote:

> 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.
>
>
This is already non-standards compliant code :)

I realize that seems like an easy handwave here, but in this case I don't
really want to support someone redefining things in our headers this way
and expect it to work.


> 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.
>
>
This code is likely Apple Internal and so wouldn't be compiled with gcc or
icc.

gcc uses a pragma for this sort of thing. I'm using an attribute. icc has
something slightly different, but the same general idea.

-eric


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