From cfe-dev Thu Jul 30 20:05:11 2015 From: Vedant Kumar Date: Thu, 30 Jul 2015 20:05:11 +0000 To: cfe-dev Subject: Re: [cfe-dev] [PROPOSAL] Reintroduce guards for Intel intrinsic headers Message-Id: <73FD8D3C-452E-41DE-9813-2BA167BFF42A () apple ! com> X-MARC-Message: https://marc.info/?l=cfe-dev&m=143828717120006 > On Thu, Jul 30, 2015 at 11:27 AM Vedant Kumar wrote: > > On Jul 30, 2015, at 10:33 AM, Eric Christopher 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