[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: Vedant Kumar <vsk () apple ! com>
Date: 2015-07-30 20:05:11
Message-ID: 73FD8D3C-452E-41DE-9813-2BA167BFF42A () apple ! com
[Download RAW message or body]
> 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.
Ah ok, I think I understand. If we want the extra granularity, we can't block off \
some of the symbols in the preprocessor because some function could need them.
Sean's suggestion of putting this behind a flag sounds nice, but the details are \
hairy. We might have to provide a separate set of headers for people who want the \
feature guards.. and it's not clear whether the flag would be gcc-compatible.
vedant
_______________________________________________
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