On Tue, Jun 23, 2015 at 1:21 PM, Eric Christopher <echri...@gmail.com> wrote:
> > > On Tue, Jun 23, 2015 at 12:03 PM Akira Hatanaka <ahata...@gmail.com> > wrote: > >> On Mon, Jun 22, 2015 at 2:00 PM, Eric Christopher <echri...@gmail.com> >> wrote: >> >>> >>> >>> On Mon, Jun 22, 2015 at 1:49 PM Akira Hatanaka <ahata...@gmail.com> >>> wrote: >>> >>>> In http://reviews.llvm.org/D10414#191915, @echristo wrote: >>>> >>>> > Another possibility is that this gets mapped as a normal command line >>>> option passed into cc1 and then it can just be a subtarget feature? >>>> >>>> >>>> Would it look something like this in the IR? >>>> >>>> "target-features"="+neon,+vfp3,arn-restrict-it=false" >>>> >>> >>> was thinking of more just: >>> >>> "target-features"="+neon,+vfp3,-restrict-it" >>> >>> Though if we're going for "restrict-it" blocks perhaps a better name >>> that works well with +/-? >>> >>> I've generally stayed away from turning command line options into >>> features, but in the case of something that appears to turn on actual code >>> generation features it seems like it might be reasonable. >>> >>> >> Since restrict-it is a tri-state, I think you'll have to define two new >> subtarget features in ARM.td (see the attached patch). I'm not sure how >> prefixing "restrict-it" by "-" is going to work. >> > > I think default is a red herring here a bit. It's either on or off right > now, we might have to bake in some back end knowledge in the front end > about when to apply it, but it should still work out yes? > > Yes, we'll have to know whether "restrict-it" or "no-restrict-it" was passed on command line and whether v8 is supported. >> This approach can potentially create larger numbers of subtarget objects >> as two subtarget objects have to be created If one function has feature >> "restricted-it" and another has feature "no-restricted-it". If we take the >> approach in my original patch, we need only one subtarget object. Do you >> think that's going to be a problem? >> >> > Irrespective of the above I'm not too worried about this. In general, > people have a tendency to use the same command line options everywhere, > especially for this sort of thing. > > I would think so too. -eric > > >> -eric >>> >>> >>>> >>>> >>>> http://reviews.llvm.org/D10414 >>>> >>>> EMAIL PREFERENCES >>>> http://reviews.llvm.org/settings/panel/emailpreferences/ >>>> >>>> >>>>
_______________________________________________ cfe-commits mailing list cfe-commits@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits