Displaying 3 results from an estimated 3 matches for "getcanonicalarchname".
2016 Jan 05
3
Diff to add ARMv6L to Target parser
...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...
2016 Jan 06
2
Diff to add ARMv6L to Target parser
...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”
>>...
2016 Jan 05
6
Diff to add ARMv6L to Target parser
> 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