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

On 5 January 2016 at 09:13, Renato Golin <renato.golin at linaro.org>
wrote:
> Anyhow, Artyom's proposal is the best, IMO, to treat it like an alias
> and handle like v7A internally. If we end up needing specific
> decisions in the driver, it should stay in the driver.
That's rather a hack, given that the 'l' actually has semantic
meaning, but I suppose I could live with it.

Tim.

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.

Today, all platform decisions are in the Triple class, which is known
to be insufficient.

Until the Tuple class replaces the Triple for such uses, we'll have to
continue on the same implementation, which is to set up a triple and a
lot of other independent flags which convey the original idea.

In the Arch side, ARMv7l is *really* ARMv7A, so it should not have any
further knowledge about the rest of the environment.

Ideally, the driver should set up a Tuple object with all the
decisions, using the TargetParser *only* to map from text to enum, and
using those values to get a complete picture, also based on the
environment, etc.

Once Tuple holds all the info, we can have other enum values to mean
all other environmental options, but none of them should be in the
Arch portion.

cheers,
--renato

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.