The triple parser should only accept existing architecture names
when the triple starts with armv, armebv, thumbv or thumbebv.
Details
- Reviewers
rengolin t.p.northover jmolloy
Diff Detail
Event Timeline
Hi Gabor,
The idea is good, but I think we need a better implementation... Something that would be valid for other archs too.
As I see it, some arch strings are static (ex. "r600" or "hexagon"), and for them, a StringSwitch is the best way.
Others, like ARM ("armv*") and Intel ("i*", "x86*"), MIPS ("mips*") would better be separate on their own static inline functions returning the Triple::ArchType, not boolean. Your new function is good, but instead of boolean, change it to Triple::ArchType, and implement it for the others that have the same pattern.
cheers,
--renato
I'm not objecting to the idea, but I'm also not sure what you plan on gaining from this?
Also, tests?
-eric
Eric,
From my point of view, the issue this solves is that now you can say "-triple armvelocipede" and it'll work. That's far from ideal.
I'd prefer to have a proper parser to get arch+cpu+features from triple/march/mcpu/mfpu/mtune options, but that'll require the TargetInfo parser, which will take a while. For now, this patch would at least cover the bogus cases in ARM.
I agree some tests are in order, but I believe we already have some.
Gabor,
Have you checked for current tests on that? Are they complete? Even if they are, we should have at least a few negative tests ("RUN: not" lines) to make sure we don't accept the things we say we won't.
cheers,
--renato
Hi Renato,
Currently I see similar test cases in these Clang tests:
test/Driver/hexagon-toolchain.c
test/Driver/mips-abi.c
I plan to write similar Clang test cases checking for this error message
"error: unknown target triple 'armvelocipede--linux-gnueabi'"
when the ARM target triple is invalid, for example if we call clang like this:
"clang -target armvelocipede--linux-gnueabi"
and so forth with armebv, thumbv and thumbebv.
By the way, how does one submit patches that modify both clang and llvm?
Thanks,
Gabor
Hi Gabor,
You need to create two reviews, one for each, and cross reference each other (in the text, writing DNNNN will link automatically).
However, LLVM changes normally have to be self-contained, so you should have tests in the LLVM side as well. I believe using llc for that should work.
When it gets to commit, you should commit the LLVM part first, and aim for it to pass even without Clang being updated, since not everyone uses clang. Clang commits can depend on LLVM ones, and that's why you need to commit to LLVM first.
cheers,
--renato
Hi Renato,
I changed the ARM triple parsing function as you requested,
and added tests on LLVM side.
As for the triple starting with "i*", "x86*" and "mips*" I think
these cases can be easily handled by enumerating all possible
cases (there aren't so many as ARM cases), but if you still think
that these cases should be handled in their separate function
I will refactor the patch.
lib/Support/Triple.cpp | ||
---|---|---|
270 | Can't we just say: .StartsWith("arm", parseARMArch(ArchName)) .StartsWith("thumb", parseARMArch(ArchName)) and add "arm64" to parseARMArch? Maybe even adding "aarch64" to it, too, and having: .StartsWith("arm", parseARMArch(ArchName)) .StartsWith("thumb", parseARMArch(ArchName)) .StartsWith("aarch64", parseARMArch(ArchName)) I wonder how Tim/James would feel about that... |
Hi Renato,
Simplified parseARMArch calls as requested.
Also added "arm64" and "aarch64".
Thanks Gabor, I don't think we need tests of the correct archs, since they're used all over the place.
The implementation is looking a lot better, thanks!
-renato
Can't we just say:
and add "arm64" to parseARMArch?
Maybe even adding "aarch64" to it, too, and having:
I wonder how Tim/James would feel about that...