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)
Details
Diff Detail
- Repository
- rL LLVM
Event Timeline
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:
- Adding SubTargetFeatureBits everywhere.
- Changing the AsmParser to take a string for barriers etc (this seems orthogonal to me)
- 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; |
Hi James,
thank you for comments. I will update the revision with
- Changing the AsmParser to take a string for barriers etc
and then provide two more patches for
- Adding SubTargetFeatureBits everywhere.
- 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 |
Patch has been separated by four parts:
- http://reviews.llvm.org/D8579 [AArch64] Move initializations of AArch64NamedImmMapper out of void AArch64Operand::print(...)
- http://reviews.llvm.org/D8582 [AArch64] Rename Pairs to Mappings in AArch64NamedImmMapper
- (this revision) introduction of FeatureBits to AArch64NamedImmMapper::Mapping
- http://reviews.llvm.org/D8584 [AArch64] Handle Cyclone-specific register in common way
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
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?
A better question might be:
Why are all of these classes copying the feature sets and using them with
their own API?
-eric
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
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. |
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.
This is a pretty terrible name. What do you mean here?