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

[William Dillon via llvm-dev]

Hi all,

Thank you so much for this discussion.  It has been very helpful and educational.  I think that I understand the perspectives of both Tim and Renato.  Let me briefly summarize them to ensure that I correctly understand:

Renato’s perspective is that the triple means whatever the author says it does, and that may or not be meaningful.  :) In the case of armv7l (for example) it has a clear meaning: ARMv7A little endian.  Unfortunately, this nomenclature collides with what is used for sub-architectures.  ARMv7l, however, is NOT a sub-architecture, and should not be treated as one.

Tim’s perspective is that what Renato says isn’t wrong, but that while the logic currently used to map armv7l into something meaningful is not great, it is certainly not unacceptable.  Given that armv7l is already treated in this way, it is not unreasonable to also support armv6l.

How is this for a proposed solution?  What if I add logic to llvm::ARM::getCanonicalArchName() <https://github.com/apple/swift-llvm/blob/stable/lib/Support/TargetParser.cpp#L387> 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.

Thoughts?
- Will

> On Jan 5, 2016, at 4:48 AM, Renato Golin via llvm-dev <llvm-dev at lists.llvm.org> wrote:
> 
> On 5 January 2016 at 12:33, Tim Northover <t.p.northover at gmail.com> wrote:
>> I know they don't make sense in many corner cases, but I think
>> discarding logic where it *does* exist is a mistake.
> 
> We're not discarding any logic. As I said, the architecture name
> cannot be ARMv7L for any reason. It's that simple.
> 
> The logic, if it exists, need to be encoded somewhere else.
> 
> 
>> I do know this, Renato.
> 
> I only meant as an opener, not as education. I know you know this...
> 
> 
>> 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.
> 
> I cannot separate between A and R if both use the same arch name.
> Knowing the sub-arch is as important than knowing its byte-sex, and I
> can't trade one for the other.
> 
> If the Driver/Triple/Tuple knows which, depending on other
> information, then they should be the ones encoding this.
> 
> Adding an *Arch Name* ARMv7L will make no progress in understanding
> what it is. Encoding the correct fields in the Triple/Tuple will, and
> for that, ARMv7A or ARMv7R are the *correct* "arch names".
> 
> cheers,
> --renato
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160105/bea1f650/attachment.html>