[llvm-dev] Diff to add ARMv6L to Target parser

[Renato Golin via llvm-dev]

On 5 January 2016 at 11:40, Tim Northover <t.p.northover at gmail.com> wrote:
> I disagree. "armv7l" is created specifically by Linux appending a
> little-endian 'l' to an "armv7" base. It's much less common (because
> no-one cares about big-endian), but "armv7b" also exists.

You assume triples make sense. That's the first mistake everyone does
when thinking about triples. :)

Triples are only random strings that mean whatever the original author
wants it to mean. "ARMv7L", so far, has been used to generically
represent "ARMv7A little endian".

AFAIK, "ARMv7B" is only used by HighBank, which is no more. But that,
too, was "ARMv7A big endian".


> As do
> "armv6l", "armv6b" and probably "armv8" equivalents too if you ran a
> 32-bit kernel there. Adding random aliasing on an ad-hoc basis doesn't
> scale or represent what's really going on.

That is not random, and that's what you're missing. Those are
"Architecture Names", not triples, not sub-architecture, not
environment markers, not vendors choices.

The ARM documents define a list of official architecture names, and
those are the ones supported by the TargetParser. What the
Triple/Tuple supports is completely orthogonal.

So, in the TargetParser, there can be no "ARMv7L" nor "ARMv7B", only
"ARMv7A". The other strings map to ARMv7A because that's what they
generally mean, in the wild, with regards to "architecture names". The
hack is that the Driver/Triple/Tuple are using that to mean everything
else.

The Parser also extracts the sub-architecture string ("v7l" etc), so
the Triple/Tuple classes can reason some more about it on their own,
to change the other sub-architecture and vendor specific options. Some
places do that, others don't.

So, this patch doesn't fix the whole thing, because the fix is *not*
in the TargetParser, but in the Driver, the Triple, the Tuple, etc.
The Parser suggestion by Artyom is correct, the fix for the problem is
not.


> What does RTLinux on an R-class CPU present itself as? My guess would
> be "armv7l" too.

Nope. GNU triples have a very specific meaning because that's what's
generated from the configure-time options. That means different
choices generate different triples, otherwise, you wouldn't be able to
build packages or sysroots for different environments (multiarch /
multilib). Therefore, different sub-architecture levels end up with
different triple names.

Furthermore, distributions choose different options for the same
triples, and the same options for different triples, and they like it
so much that they're pushing me to add CMake-time default options into
LLVM to simulate that. So, in the end, "ARMv7L" means completely
different things for different Linux distributions. This is *really* a
job for the Tuple, not a simple parser that relies on Table-Gen'd ARCH
names.

cheers,
--renato