[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 18:33:08
Message-ID: CALehDX6h+SzRhZfvj0qD3rz0KEWeCydz9wGEOhOWTfghj7zkWA () mail ! gmail ! com
[Download RAW message or body]

[Attachment #2 (multipart/alternative)]


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.


>
> 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

[Attachment #5 (text/html)]

<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Thu, Jul 30, 2015 \
at 11:27 AM Vedant Kumar &lt;<a href="mailto:vsk@apple.com">vsk@apple.com</a>&gt; \
wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 \
.8ex;border-left:1px #ccc solid;padding-left:1ex">&gt; On Jul 30, 2015, at 10:33 AM, \
Eric Christopher &lt;<a href="mailto:echristo@gmail.com" \
target="_blank">echristo@gmail.com</a>&gt; wrote:<br> &gt;<br>
&gt;&gt; I don&#39;t see any downsides to reintroducing these guards.<br>
&gt;<br>
&gt; Then you weren&#39;t really paying attention to the point of removing them \
:)<br> &gt;<br>
&gt; 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&#39;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&#39;t use any of those symbols?<br> \
<br></blockquote><div><br></div><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&#39;ll want to be able to use the intrinsics at the same time. It won&#39;t work \
if you block them at the preprocessor level.</div><div>  </div><blockquote \
class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc \
solid;padding-left:1ex"><br> I&#39;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><div>Did the above \
help?</div><div><br></div><div>-eric  </div></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