This is an archive of the discontinued LLVM Phabricator instance.

[ARM] Correct ARMv8*-A optional extension definitions in TargetParser
ClosedPublic

Authored by richard.barton.arm on Aug 15 2016, 4:32 AM.

Details

Summary
The ARMv8*-A descriptions in the ARM and AArch64 TargetParsersa are incorrect
architecturally and mismatched to the backend descriptions.

RAS is an optional extension to ARMv8-A and ARMv8.1-A and mandatory in
ARMv8.2-A. Correct the ARMTargetParser descriptions which had this as enabled
by default in the earlier versions.

The FP16 and SPE extensions are optional in ARMv8.2-A and the backend defaults
them as off. They are not available as extensions to earlier ARMv8-A versions.
Correct the AArch64TargetParser which had these as enabled by default in all
ARMv8-A definitions.

These macros are only used to define preprocessor macros. There are no macros
yet as ACLE has not caught up with ARMv8.2-A so not possible to add a test.

Diff Detail

Repository
rL LLVM

Event Timeline

richard.barton.arm retitled this revision from to [ARM] Correct ARMv8*-A optional extension definitions in TargetParser.
richard.barton.arm updated this object.
richard.barton.arm added a reviewer: jojo.
richard.barton.arm added a subscriber: llvm-commits.

Looks reasonable to me, but we ought to be able to add MC tests (or even unittests) to make sure it sticks.

rengolin edited edge metadata.Aug 16 2016, 10:13 AM

Shouldn't be hard to add unit tests...

jojo edited edge metadata.Aug 16 2016, 6:59 PM

I have checked the TargetParser and related unittests, the change is reasonable and enough.
LGTM!

jojo accepted this revision.Aug 17 2016, 6:33 PM
jojo edited edge metadata.
This revision is now accepted and ready to land.Aug 17 2016, 6:33 PM

JoJo: two of us have asked for tests. Are you seeing something we're not?

jojo added a comment.Aug 17 2016, 10:49 PM

Hi Tim,

I have checked the TargetParser. no addtional tests are needed for TargetParser as i see.
Please let me know if you find something that I may missed. :)

Hi Tim,

Some of the TargetParser tests are automatic, with both the tests and the checks generated from the same tables, so they will continue to stress those lines.

The validity of this technique may be discussed, and tests changed, but I don't think it should be related to this commit.

cheers,
--renato

Ah, I see. Didn't realise that.

Hi all - I was puzzling over how to write a new unit test that would catch this error without just copying the structure of the target parser itself. The best I could come up with is to define a for each architecture extension, a set of all architectures that must enable it by default. You could then iterate over all the extensions and for each check all the architectures and test that those in the set have the enum set and those not in the set do not.

So like:

const char *RASDefaultArches[] = { "armv8.2-a"};
..
const struct {AArch64::ArchExtKind Ext, const char *DefaultArches[] } Defaults[] =  {
    {AArch64::AEK_RAS, RASDefaultArches },
    ...
};
for D in Defaults:
  for Ext in D.first():
    for Arch in AllArches:
      ASSERT(Arch in D.second() ? Arch.ArchBaseExtensions & Ext : !(Arch.ArchBaseExtensions & Ext))

Does seem a little contrived though. If you all are happy with the existing testing then I will land the patch as-is. Happy to work on further tests if they are needed. When the ACLE catches up then we can test these properly I think.

const char *RASDefaultArches[] = { "armv8.2-a"};
..
const struct {AArch64::ArchExtKind Ext, const char *DefaultArches[] } Defaults[] = {

{AArch64::AEK_RAS, RASDefaultArches },
...

};
for D in Defaults:

for Ext in D.first():
  for Arch in AllArches:
    ASSERT(Arch in D.second() ? Arch.ArchBaseExtensions & Ext : !(Arch.ArchBaseExtensions & Ext))
Does seem a little contrived though. If you all are happy with the existing testing then I will land the patch as-is. Happy to work on further tests if they are needed. When the ACLE catches up then we can test these properly I think.

This would be the pattern that I was expecting, yes, but for all arches / extensions.

My problem with that technique is that new arches / extensions won't fail the tests, so may get away with not adding tests, but I don't have a good strategy to make it break if a new extension is added... Maybe this could be two tests, or a complicated one...

I'm open to suggestions. I also don't mind this commit going as is and you adding some more generic tests later.

But I think these tests will need reviewing one way or another.

This revision was automatically updated to reflect the committed changes.