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

[Renato Golin via llvm-dev]

On 5 January 2016 at 17:24, William Dillon <william at housedillon.com> wrote:
> How is this for a proposed solution?  What if I add logic to
> llvm::ARM::getCanonicalArchName() that matches the trailing ‘l’ (or ‘b’) and
> treats it the same way that ‘el’ and ‘eb’ are now?  This function would
> return v7 or v6 in the case of armv7l or armv6l, respectively (or, if it’s
> preferred, v7a or v6a).  It seems like this is closer to the “correct”
> approach.  It does show potentially inappropriate deference to Linux’s
> choice in the matter, but at least it’s not making sub-architectures that
> don’t exist.

This is the final "better" solution, but it can't be implemented right
now due to current expectations of what "armv7l" and "armv6l" mean.

If you return "v7" from "armv7l", it'll set the arch to generic ARMv7
which has none of the current ARMv7A attributes that makes code runs
*much* faster. That would be a major regression in performance.

The quick hack is to leave "armv7l" as it is, add "armv6l" to the
expected "armv6?" variant that means RaspberryPi, and add a number of
FIXMEs to the parser:
 1. To remove both L/B variants as aliases
 2. To implement L/B in getCanonical in the same way as EB/BE
 3. But only once Triple/Tuple can replace the "v7l" -> "v7a when
Linux" OR "v7R when RTLinux" logic (I have no idea how this will pan
out).

To know about the progress on Tuple, check with Daniel Sanders and
Eric Christopher (CC'd).

Adding this hack to the Driver now could make the mess even worse at this stage.

cheers,
--renato