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

[Tim Northover via llvm-dev]

> 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.