[llvm] r273148 - [AARCH64] Add support for Broadcom Vulcan

[Eric Christopher via llvm-commits]

On Mon, Jun 20, 2016 at 2:42 PM Renato Golin <renato.golin at linaro.org>
wrote:

> On 20 June 2016 at 21:50, Eric Christopher via llvm-commits
> <llvm-commits at lists.llvm.org> wrote:
> > So, why are all of the processors given as SubtargetFeatures as well as
> > processors? This seems ... less than optimal. I.e. I can't come up with a
> > reason I'd want to say "llc -mattr=+vulcan" rather than llc -mcpu=vulcan.
>
> Those features are not only for llc -mattr, but they define what
> features a target will have and it's a convenient way to group things
> together without specifying Target.isCortexA53().
>
>
OK... this in particular isn't a great reason (there's an actual good one
below :)

The best thing is to define concats perhaps the way that the PPC backend
does it.

Something like this for example:

def ProcessorFeatures {
  list<SubtargetFeature> Power7FeatureList =

I'd definitely much rather you take the core ISAs perhaps as features and
then add extensions on top of that as additional subtarget features. Would
probably be pretty clean as well.


> Maybe it could be done in a different way, but this has been the way
> for a long time now, and AArch64 only copied from ARM. :)
>
>
This is a good explanation though ;)


> I don't think anyone does (or should) use it in -mattr anyway. Maybe
> mattr is another candidate for using the target parser...
>

Definitely shouldn't be used.

That said, one way I've seen these sorts of things being used is via
ST->isCPUX() for TTI and a few other things which is fairly valid. We might
need a better way of doing that, basically defining the name of the cpu as
a subtarget feature is a bit wonky really.

-eric
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20160620/fb322a3c/attachment.html>