> > >>>>> >>>> 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. >> >> > As per your suggestion, I added one feature in ARM.td and then fixed > getARMTargetFeatures in lib/Driver/Tools.cpp to push feature "+restrict-it" > to the feature list based on the subarch. > > It seems to me that we can add code-gen options to the IR as subtarget > features in most cases, but it's not clear to me when to use function > attributes and when to use subtarget features. Should we convert > target-specific code-gen options into subtarget features whenever it is > possible to do so, and convert target-independent options into function > attributes? > > This is what I've been thinking at the moment. I think it cleans up quite a bit of the interface mechanics etc. I've even added one more target-independent one (soft-float) as a subtarget feature because that seems to make the most sense. I think at least some of these are going to be on a case by case basis, but this seems to make the most sense to me.
-eric > >>>> 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
