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

Eric Christopher via llvm-commits llvm-commits at lists.llvm.org
Tue Jun 21 15:31:53 PDT 2016


On Tue, Jun 21, 2016 at 3:18 PM Matthias Braun <mbraun at apple.com> wrote:

> On Jun 20, 2016, at 1:50 PM, Eric Christopher via llvm-commits <
> llvm-commits at lists.llvm.org> wrote:
>
>
>>
>> +def ProcVulcan  : SubtargetFeature<"vulcan", "ARMProcFamily", "Vulcan",
>> +                                   "Broadcom Vulcan processors", [
>> +                                   FeatureFPARMv8,
>> +                                   FeatureNEON,
>> +                                   FeatureCrypto,
>> +                                   FeatureCRC,
>> +                                   HasV8_1aOps]>;
>> +
>>
>
> 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.
>
>
> Yes the pattern is strange. But there is one problem today: We want to
> initialize a bunch of cost values. This is currently done in
>  Arch64::Subtarget::initializeProperties(). These costs are really per CPU
> so we need to set the ProcFamily enum per CPU. Initializing the cost values
> together with the processor definition in tablegen would have been nicer
> but is not sanely possible today.
> (Using the SubtargetFeatures doesn't cut it, because I need 1 feature for
> each variable+value combination, the generated code always goes for the
> minimum in case the var is initialized multiple times while I sometimes
> want max, I shouldn't have boolean -mattrs for initializing cost values,
> etc.)
>
>
Agreed, setting a table of TTI values might be nice. Some other targets
just switch on features that exist, and I can't come up with another way to
do this cheaply (there's always StringSwitch!) in every place that should
be returning the values in TTI (as an example) without needing an explicit
switch on strings. The cost values can definitely be stored in the
subtarget, but you don't necessarily need a SubtargetFeature for a cpu as a
way of setting things up - you can use the CPU value.

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


More information about the llvm-commits mailing list