[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: Sean Silva <chisophugis () gmail ! com>
Date: 2015-07-30 19:02:20
Message-ID: CAHnXoamsOCgG+z4DHxFVS-O2dGb7TAg3en=m5JQUk-YiZS8MYg () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
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.
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@cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>
>
[Attachment #5 (text/html)]
<div dir="ltr"><br><div class="gmail_extra"><br><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 \
class=""><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><br \
class="Apple-interchange-newline">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>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><br></div><div>-- Sean Silva</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_quote"><span class=""><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 class="HOEnZb"><font color="#888888"><div><br></div><div>-eric \
</div></font></span></div></div> \
<br>_______________________________________________<br> cfe-dev mailing list<br>
<a href="mailto:cfe-dev@cs.uiuc.edu">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><br></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