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

[William Dillon via llvm-dev]

Taking the suggestions of the group under consideration, I’ve generated a new diff.  The thing to note is that armv6l is now treated identically to armv6hl.  I’ve also added a unit test.
This seems to me to be the least invasive method, and holds to existing conventions as closely as possible.

Thoughts?

-------------- next part --------------
A non-text attachment was scrubbed...
Name: llvm-armv6l.diff
Type: application/octet-stream
Size: 2198 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160106/31b7528c/attachment.obj>
-------------- next part --------------

> On Jan 5, 2016, at 9:51 AM, Renato Golin <renato.golin at linaro.org> wrote:
> 
> 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