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.
Details
Diff Detail
Event Timeline
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.
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.
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 | 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 | 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 | I guess there isn't a v5 without Thumb... |
Yes I did delete them (lines 77-111 in ARMTargetParser.def)
include/llvm/Support/ARMTargetParser.def | ||
---|---|---|
183 | 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 | 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:
|
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.
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?