[prev in list] [next in list] [prev in thread] [next in thread]
List: cfe-dev
Subject: Re: [cfe-dev] [PROPOSAL] Reintroduce guards for Intel intrinsic headers
From: Eric Christopher <echristo () gmail ! com>
Date: 2015-07-30 19:47:27
Message-ID: CALehDX7FCSD-5vz6EKJ6JPZBeixcdJBm8pSByaVdK2PLtGeUOw () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
On Thu, Jul 30, 2015 at 12:02 PM Sean Silva <chisophugis@gmail.com> wrote:
> On Thu, Jul 30, 2015 at 11:33 AM, Eric Christopher <echristo@gmail.com>
> wrote:
>
>>
>>
>> On Thu, Jul 30, 2015 at 11:27 AM Vedant Kumar <vsk@apple.com> wrote:
>>
>>> > On Jul 30, 2015, at 10:33 AM, Eric Christopher <echristo@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@cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>>
>>
[Attachment #5 (text/html)]
<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Thu, Jul 30, 2015 \
at 12:02 PM Sean Silva <<a \
href="mailto:chisophugis@gmail.com">chisophugis@gmail.com</a>> \
wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 \
.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div \
class="gmail_extra"><div class="gmail_quote">On Thu, Jul 30, 2015 at 11:33 AM, Eric \
Christopher <span dir="ltr"><<a href="mailto:echristo@gmail.com" \
target="_blank">echristo@gmail.com</a>></span> wrote:<br><blockquote \
class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc \
solid;padding-left:1ex"><div dir="ltr"><br><br><div class="gmail_quote"><span><div \
dir="ltr">On Thu, Jul 30, 2015 at 11:27 AM Vedant Kumar <<a \
href="mailto:vsk@apple.com" target="_blank">vsk@apple.com</a>> \
wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 \
.8ex;border-left:1px #ccc solid;padding-left:1ex">> On Jul 30, 2015, at 10:33 AM, \
Eric Christopher <<a href="mailto:echristo@gmail.com" \
target="_blank">echristo@gmail.com</a>> wrote:<br> ><br>
>> I don't see any downsides to reintroducing these guards.<br>
><br>
> Then you weren't really paying attention to the point of removing them \
:)<br> ><br>
> The idea is so that the headers can be used, with appropriate target attributes, \
for any code.<br> <br>
Right, I thought about this but wasn't sure if there were benefits to having \
symbols available for an unsupported target.<br> <br>
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?<br> \
<br></blockquote><div><br></div></span><div>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.</div></div></div></blockquote><div><br></div></div></div></div><div \
dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><br>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.</div><div><br></div></div></div></div></blockquote><div><br></div><div>This \
is already non-standards compliant code :)</div><div><br></div><div>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.</div><div> \
</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc \
solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div \
class="gmail_quote"><div></div><div>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.</div></div></div></div><div dir="ltr"><div class="gmail_extra"><div \
class="gmail_quote"><div><br></div></div></div></div></blockquote><div><br></div><div>This \
code is likely Apple Internal and so wouldn't be compiled with gcc or \
icc.</div><div><br></div><div>gcc uses a pragma for this sort of thing. I'm using \
an attribute. icc has something slightly different, but the same general \
idea.</div><div><br></div><div>-eric</div><div> </div><blockquote \
class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc \
solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div \
class="gmail_quote"><div></div><div>-- Sean Silva</div><div> \
</div></div></div></div><div dir="ltr"><div class="gmail_extra"><div \
class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 \
.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div \
class="gmail_quote"><span><div> </div><blockquote class="gmail_quote" \
style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br> 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).<br><br></blockquote><div><br></div></span><div>Did the above \
help?</div><span><font color="#888888"><div><br></div><div>-eric \
</div></font></span></div></div> <br></blockquote></div></div></div><div \
dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><blockquote \
class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc \
solid;padding-left:1ex">_______________________________________________<br> cfe-dev \
mailing list<br> <a href="mailto:cfe-dev@cs.uiuc.edu" \
target="_blank">cfe-dev@cs.uiuc.edu</a><br> <a \
href="http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev" rel="noreferrer" \
target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev</a><br> \
<br></blockquote></div></div></div></blockquote></div></div>
_______________________________________________
cfe-dev mailing list
cfe-dev@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic