llvm dev - Jan 2016 - Diff to add ARMv6L to Target parser

On 5 January 2016 at 10:55, Renato Golin <renato.golin at linaro.org>
wrote:
> On 5 January 2016 at 10:28, Tim Northover <t.p.northover at
gmail.com> wrote:
>> That's rather a hack, given that the 'l' actually has
semantic
>> meaning, but I suppose I could live with it.
>
> Not really.
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. 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.
> In the Arch side, ARMv7l is *really* ARMv7A, so it should not have any
> further knowledge about the rest of the environment.
What does RTLinux on an R-class CPU present itself as? My guess would
be "armv7l" too. I'm not too concerned about deciding that we only
care about A-class Linux, but I am concerned about taking an
unprincipled approach to the l/b suffix.

Not enough that I can't live with it though. As you say this whole
area's enough of a mess already, one more bit isn't going to break the
world.

Cheers.

Tim.

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

> You assume triples make sense. That's the first mistake everyone does
> when thinking about triples. :)
I know they don't make sense in many corner cases, but I think
discarding logic where it *does* exist is a mistake.
> AFAIK, "ARMv7B" is only used by HighBank, which is no more. But
that,
> too, was "ARMv7A big endian".
I believe it's what any Linux kernel will present itself as via "uname
-a" which, as James said, is a vaguely sane way to seed a triple.
> 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.
I do know this, Renato.
> 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.
Sure. In exactly the same way there's no "armebv7" in
TargetParser.
There's principled(ish) parsing of the "eb" when deciding what the
triple actually means though.
>> 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.
I have no idea what you're objecting to here. I wasn't saying anything
about how GNU interprets the armv7l that would be produced, just that
I would expect running "uname" on an R-class Linux to produce armv7l.

Tim.