[PATCH] D10969: Replace Triple with a new TargetTuple in MCTargetDesc/* and related. NFC.

[Daniel Sanders via llvm-commits]

dsanders added a comment.

This project has stalled for a while so to try to get things moving again: The llvmdev thread goes into more detail but the major goals of the project this patch is part of include:

- Fix the incorrect assumption that GNU triples describe a single specific target.
- Allow vendors/distributions to configure the triple meanings to suit their target. Different vendors/distributions often have conflicting meanings for the same triple and the meanings change over time
- Minimize the amount of LLVM that needs to be aware of GNU triple ambiguity (same triple but different meaning).
- Minimize the amount of LLVM that needs to be aware of GNU triple aliases (different triple but same meaning).
- Minimize the occasions where the GNU triple is parsed.

ARM and Mips are the main beneficiaries of this since our respective toolchain histories have made our GNU triples a big mess of ambiguity and inconsistency. However, other architectures (including X86) also share these problems to varying degrees.

The high level plan that was discussed in the 'The Trouble With Triples' thread was:

> 1. Replace any remaining std::string's and StringRef's containing GNU triples with Triple objects.

> 2. Split the llvm::Triple class into llvm::Triple and llvm::TargetTuple classes. Both are identical in implementation and almost identical in interface at this stage.

> 3. Gradually replace Triples with TargetTuples until the C APIs and the LLVM-IR are the only place inside LLVM where Triples are still used.

> 4. Change the implementation of TargetTuple to whatever is convenient for LLVM's internals and decide on a serialization.

> 5. Replace serialized Triples with serialized TargetTuples in LLVM-IR. a. Maintain backwards compatibility with IR using triples, at least for a while.

> 6. Add TargetTuple support to the C API. Exact API is t.b.d.

> 7. Have the API users mutate the TargetTuple appropriately.


Step 5 was a little controversial on that thread, but it's not a significant change to the plan to keep the GNU triple around for LLVM-IR's purposes.

This patch is step 2 and the first piece of step 3. My current branch has ~90% of step 3 complete and can be found at https://github.com/dsandersimgtec/llvm/tree/triple-trouble if you'd like to peek at some of the patches that will follow this one.


http://reviews.llvm.org/D10969