jyknight added a comment.
In general, I think it's extremely unfortunate that Clang and LLVM have
different copies of the same information. It's a problem for way more than just
this one situation. So, I really don't like choice 1 -- I think it's moving in
the wrong direction.
The recent thread about compiler-rt libcalls vs size of "int" is another
example of this sort of issue of duplicated info across the llvm/clang boundary
being troublesome. Other times, the information in question is buried in the
Target implementation in LLVM, and Clang doesn't depend upon targets being
compiled in...usually, so it can't access it from there. E.g. the fact that
Clang even has to come up with a DataLayout string on its own is an example of
this problem.
So, I like option 2. I think a lot more of the information in TargetInfo ought
to be shared with LLVM. I note that ARM already pushed a bunch of shared stuff
into LLVM to reduce duplication, which is great. But, it had to put it into a
rather odd place
(`llvm/include/llvm/Support/{ARMTargetParser.h,ARMAttributeParser.h,...`),
because of the layering and optionality concerns. That part is not so great --
putting all this target-specific info into "Support" doesn't feel like the best
fit. There should be some sort of Target-specific location for this sort of
stuff to live which Clang can depend on.
Repository:
rL LLVM
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D17183/new/
https://reviews.llvm.org/D17183
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
