This is an archive of the discontinued LLVM Phabricator instance.

Cull non-standard variants of ARM architectures (NFC)
ClosedPublic

Authored by tyomitch on Nov 11 2015, 10:20 AM.

Details

Summary

This patch changes ARMV5, ARMV5E, ARMV6SM, ARMV6HL, ARMV7, ARMV7L,
ARMV7HL, ARMV7EM to be treated as aliases for the corresponding
standard architectures, instead of as actual architectures.

Diff Detail

Repository
rL LLVM

Event Timeline

tyomitch updated this revision to Diff 39942.Nov 11 2015, 10:20 AM
tyomitch retitled this revision from to Cull non-standard variants of ARM architectures (NFC).
tyomitch updated this object.
tyomitch added a reviewer: rengolin.
tyomitch added a subscriber: llvm-commits.
rengolin edited edge metadata.Nov 11 2015, 12:43 PM

What's the motivation behind this?

These names are used for -march and triples, which are still in use by many build systems out there (and why they were introduced in the first place).

I don't see why we'd want to remove them, other than break legacy systems.

What's the motivation behind this?

These names are used for -march and triples, which are still in use by many build systems out there (and why they were introduced in the first place).

I don't see why we'd want to remove them, other than break legacy systems.

The motivation is to still accept them in -march and triples (as aliases), while cleaning them out of the rest of the source code.

The user interface stays unaffected.

The motivation is to still accept them in -march and triples (as aliases), while cleaning them out of the rest of the source code.

The user interface stays unaffected.

No, it doesn't. You're removing more than you're putting back.

Even if all current tests continue to pass, it doesn't mean that the change has no functional changes, just that the tests weren't picking all the changes up.

For example, you're changing v7hl into v7-a, which in itself is "correct" but can have unpredictable side effects on corner cases. Those functions are called all over the place for different reasons, some of them only relevant to the internal logic of the function, like depending on the sub-arch, choose different options. These places are used on Linux, bare-metal, Darwin and Windows, with different results for each one.

The original state was that every place had its own parsing, which was really bad. Now, all of them are using the same parsing, but that raises a lot of bloat, redundancies and non-canonical naming, which is still bad, but not as much.

Removing a lot of legacy like this is bound to break a lot of things we aren't testing for, for no other reason than "just a clean up".

Normally, I'd be supportive of clean ups, but this part is a minefield, and we have been bitten before, every time we assume something was not being used any more. I don't think it's a good idea.

The motivation is to still accept them in -march and triples (as aliases), while cleaning them out of the rest of the source code.

The user interface stays unaffected.

No, it doesn't. You're removing more than you're putting back.

Even if all current tests continue to pass, it doesn't mean that the change has no functional changes, just that the tests weren't picking all the changes up.

For example, you're changing v7hl into v7-a, which in itself is "correct" but can have unpredictable side effects on corner cases. Those functions are called all over the place for different reasons, some of them only relevant to the internal logic of the function, like depending on the sub-arch, choose different options. These places are used on Linux, bare-metal, Darwin and Windows, with different results for each one.

I don't see what you mean.
I'm removing all uses of AK_ARMV7HL as part of the patch; there were only two, and in both cases it was treated identically to AK_ARMV7A.
How can, therefore, my change introduce any change in functionality?

So, you removed the CPU names, but not the arch names. Try removing the AK_* types from the CPUs that you remove and see if anything breaks...

include/llvm/Support/ARMTargetParser.def
183 ↗(On Diff #39942)

Did you look through all the options that use AK_ARMV5TE or AK_XSCALE? Are they always being treated in the same way every time?

233 ↗(On Diff #39942)

This CPU name was an old one that was added for some reason I don't remember... :( some GCC compatibility, I guess. IIRC, this was well before we created the TargetParser.

lib/Target/ARM/MCTargetDesc/ARMELFStreamer.cpp
704 ↗(On Diff #39942)

I guess there isn't a v5 without Thumb...

So, you removed the CPU names, but not the arch names. Try removing the AK_* types from the CPUs that you remove and see if anything breaks...

Yes I did delete them (lines 77-111 in ARMTargetParser.def)

include/llvm/Support/ARMTargetParser.def
183 ↗(On Diff #39942)

I don't touch either AK_ARMV5TE or AK_XSCALE.

These two definitions are no-ops: using "iwmmxt" or "xscale" as the CPU name is interpreted as AK_IWMMXT or AK_XSCALE, correspondingly, due to the definitions further down.

lib/Target/ARM/MCTargetDesc/ARMELFStreamer.cpp
704 ↗(On Diff #39942)

That's right: such an architecture was once defined, but deprecated straight away, and never implemented by any vendor.

https://www.scss.tcd.ie/~waldroj/3d1/arm_arm.pdf (dated 2005) says:

The valid architecture variants are as follows (variant in brackets for legacy reasons only):

  • ARMv4, ARMv4T, ARMv5T, (ARMv5TExP), ARMv5TE, ARMv5TEJ, and ARMv6

The following architecture variants are now OBSOLETE:

  • ARMv1, ARMv2, ARMv2a, ARMv3, ARMv3G, ARMv3M, ARMv4xM, ARMv4TxM, ARMv5, ARMv5xM, and ARMv5TxM
rengolin accepted this revision.Nov 11 2015, 2:55 PM
rengolin edited edge metadata.

Sigh, the target parser used to make sense, now I don't remember half of the decisions, and they're all washed and moved everywhere.

I guess the best way forward is, indeed, to simplify and wait for back slash.

At least if there is a legacy usage we can add them back and add tests to make sure it's explicit.

Go ahead and commit and let's see what gives.

This revision is now accepted and ready to land.Nov 11 2015, 2:55 PM

Thanks! What about the other one, ARMv6KZ-related? (D14568)

This revision was automatically updated to reflect the committed changes.