This is an archive of the discontinued LLVM Phabricator instance.

[AArch64] Refactor AArch64NamedImmMapper to become dependent on subtarget features.
ClosedPublic

Authored by vsukharev on Mar 20 2015, 2:55 PM.

Details

Summary
In order to introduce v8.1a-specific entities, Mappers should be aware of SubtargetFeatures available.
This patch introduces refactoring, that will then allow to easily introduce:
- v8.1-specific "pan" PState for PStateMapper (PAN extension)
- v8.1-specific sysregs for SysRegMapper (LOR,VHE extensions)

Diff Detail

Repository
rL LLVM

Event Timeline

vsukharev updated this revision to Diff 22382.Mar 20 2015, 2:55 PM
vsukharev retitled this revision from to [AArch64] Refactor AArch64NamedImmMapper to become dependent on subtarget features..
vsukharev updated this object.
vsukharev edited the test plan for this revision. (Show Details)
vsukharev set the repository for this revision to rL LLVM.
vsukharev added a subscriber: Unknown Object (MLST).
jmolloy requested changes to this revision.Mar 24 2015, 3:03 AM
jmolloy edited edge metadata.

Hi Vladimir,

Thanks for doing this. I think there's nothing massively contentious in your patch, but it's difficult to review because it's a merge of three different patches, as far as I can see:

  1. Adding SubTargetFeatureBits everywhere.
  2. Changing the AsmParser to take a string for barriers etc (this seems orthogonal to me)
  3. Re-bikeshedding (Pair->Mapper, if/else -> ?:)

So please separate it out into three patches, each of which can be trivially reviewed.

Cheers,

James

lib/Target/AArch64/Utils/AArch64BaseInfo.h
305

Why "SubTargetFeature == 0"? This seems strange. I would have expected just:

return SubTargetFeature & FeatureBits;
This revision now requires changes to proceed.Mar 24 2015, 3:03 AM

Hi James,
thank you for comments. I will update the revision with

  1. Changing the AsmParser to take a string for barriers etc

and then provide two more patches for

  1. Adding SubTargetFeatureBits everywhere.
  2. Re-bikeshedding (Pair->Mapper, if/else -> ?:)

Thanks, Vladimir

lib/Target/AArch64/Utils/AArch64BaseInfo.h
305

It is intended way to use for vast majority of Mappers, that don't depend on any subtargetfeature , and are present permanently. For those, SubTargetFeature field will be as default, i.e. 0. and no FeatureBits equal to 0. This makes all current mappers to remain correct, like
DAIFClr : {"daifclr", DAIFClr}
will mean
struct Mapping {
const char *Name = "daifclr";
uint32_t Value = DAIFClr;
uint64_t SubTargetFeature = 0;
};
and this hasFeature will always return true, no matter of subtargetfeatures

vsukharev updated this revision to Diff 22573.Mar 24 2015, 8:02 AM
vsukharev edited edge metadata.

Patch has been separated by four parts:

I'm going to ask you to hold on for a second on these. I'm not such a huge
fan of having asm parsers be subtarget dependent and would like to take a
look at it.

-eric

Eric, thank you for taking care.
Considering this, would you also take a look on chain of patches that are intended to use this subtarget dependency ?
http://reviews.llvm.org/D8498
http://reviews.llvm.org/D8499
http://reviews.llvm.org/D8500
Thanks, Vladimir

vsukharev added a comment.EditedMar 25 2015, 4:54 AM

Eric, AsmParser is already dependent on subtargetfeatures since http://reviews.llvm.org/rL207742 .
The approach has just been extended from SysRegMapper (plus its children MSRMapper, MRSMapper) to other mappers.
Would you comment on your doubts?

Why are you effectively reimplementing the feature sets for this class?

-eric

A better question might be:

Why are all of these classes copying the feature sets and using them with
their own API?

-eric

vsukharev updated this revision to Diff 22793.Mar 27 2015, 7:01 AM
vsukharev edited edge metadata.

As per echristo request, subtarget features are no longer stored into Mappers.

New revision is based on http://reviews.llvm.org/D8655

Eric, (or Tim?)
would you please review my last version? This had blocked the approved chain to commit
http://reviews.llvm.org/D8584 [AArch64] Handle Cyclone-specific register in common way
http://reviews.llvm.org/D8498 [AArch64] Add v8.1a "Privileged Access Never" extension
http://reviews.llvm.org/D8500 [AArch64] Add v8.1a "Virtualization Host Extensions"
http://reviews.llvm.org/D8499 [AArch64] Add v8.1a "Limited Ordering Regions" extension

jmolloy accepted this revision.Apr 16 2015, 3:21 AM
jmolloy edited edge metadata.

Hi Vlad,

Looks like a mostly mechanical change. I don't like one aspect of it, but if you change that you can commit.

Cheers,

James

lib/Target/AArch64/Utils/AArch64BaseInfo.h
285

I think this is overly convoluted for such a simple function. The same function name does different things depending on the overload (one checks Name and the other Value). I don't think this is intuitive.

Just simply:

bool isNameEqual(std::string Other, uint64_t FeatureBits=~0ULL) {
  if (AvailableForFeatures && !(AvailableForFeatures & FeatureBits))
    return false;
  return Name == Other;
}

And similarly for Value, would be more clear.

This revision is now accepted and ready to land.Apr 16 2015, 3:21 AM

Some comments inline.

-eric

lib/Target/AArch64/Utils/AArch64BaseInfo.h
283

This is a pretty terrible name. What do you mean here?

284

Comments are full sentences.

286

I'm not a fan of this interface name. isEqual taking features and not changing the name isn't very descriptive.

297

If you're taking FeatureBits now this should probably change names to make the interface more clear.

Also (and I realize this was already like this) the functions need a comment as to what they're for.

Eric, thank you for your feedback
in fact, I have already committed that as http://reviews.llvm.org/rL235089, with slight re-work, addressing last jmolloy's comment
I suspect a line of text after "Differential Revision:" line has prevented post-commit script to process auto-closing this DiffRevision properly. And I don't know at the time how should I fix that: close Revision and put links to commit and back. (Is it a way to do that at all?)
Anyway, should I address your comments as a separate follow-up patch? If so, would you please comment directly to http://reviews.llvm.org/rL235089, because things are changed a bit.

Please just make the changes I've requested in a follow-up commit. I don't
see the need to reply on another commit.

Eugene.Zelenko added a subscriber: Eugene.Zelenko.

Committed in rL235089.