Displaying 4 results from an estimated 4 matches for "v6k".
Did you mean:
16k
2016 Jan 08
2
Diff to add ARMv6L to Target parser
...257090)
+++ lib/Support/TargetParser.cpp (working copy)
@@ -401,6 +401,7 @@
.Case("v5", "v5t")
.Case("v5e", "v5te")
.Case("v6j", "v6")
+ .Case("v6l", "v6")
.Case("v6hl", "v6k")
.Cases("v6m", "v6sm", "v6s-m", "v6-m")
.Cases("v6z", "v6zk", "v6kz")
Index: unittests/ADT/TripleTest.cpp
===================================================================
--- unittests/ADT/TripleTest.cpp (r...
2016 Jan 07
2
Diff to add ARMv6L to Target parser
.../stable/include/llvm/Support/ARMTargetParser.def#L106 <https://github.com/apple/swift-llvm/blob/stable/include/llvm/Support/ARMTargetParser.def#L106>
Should I get the head of the non-swift repository and generate a new diff?
Also, I suspect that it’s not a good idea to have armv6l map to armv6k, because that seems like quite an assumption to make. Clearly, armv6 sub architectures that aren’t v6k will still be v6l in linux. (provided they’re little-endian).
I’ve already made that change, and it would be included in any revised diff that I send out.
Thanks,
- Will
> On Jan 6, 2016, at...
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
2016 Jan 06
2
Diff to add ARMv6L to Target parser
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: