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

[Daniel Sanders]

dsanders added a comment.

@echristo: Have you had chance to read the "The Trouble with Triples" thread? Do you still have concerns?


================
Comment at: include/llvm/ADT/TargetTuple.h:210
@@ +209,3 @@
+  /// ABI. A distributor may want the default to be N32 on low-memory targets
+  /// and would modify this constructor accordingly.
+  explicit TargetTuple(const Triple &GnuTT) : GnuTT(GnuTT) {}
----------------
rengolin wrote:
> dsanders wrote:
> > rengolin wrote:
> > > I don't think we should encourage people re-writing the constructor, or it would be a nightmare to investigate issues.
> > > 
> > > One could use the default constructor and set ABI to 32-bits later, which would be a simpler patch to keep for both vendor and community.
> > > 
> > This is trying to account for configure-option ambiguity in the GNU triples. For GCC, it's fairly common for distributors to change the meanings of triples using options like --with-arch, --with-cpu, --with-abi, etc. There are some target-specific options such as --with-mode to select ARM/Thumb by default and --with-nan for MIPS NAN encoding selection. I'm not sure about other targets but the MIPS options are in very common use and is likely to get more common in the near future as we try to push towards IEEE754(2008) being the conventional floating point standard on our target (we're still on 1985 for the majority of software).
> > 
> > The thinking behind this comment is that that distributors need to do this kind of thing to make LLVM's GNU triples consistent with the rest of their distribution. We can therefore save ourselves a fair bit of pain by nominating the right place to do it. The advantage, is that LLVM (and related tools) can be made to have the same Triple meaning as the rest of the distribution. The downside is that, as you say, it makes investigating issues more difficult on distributions that do change it since they'll have a different default TargetTuple for the same Triple. TargetTuples are still unique and authoratative so we can compensate for this by using the tuple to investigate issues, effectively bypassing any customizations the distributor made in this constructor. Frontends may need to add command line options to allow TargetTuple's (or we could claim an unused subset of the triple strings) but that should be easy. We don't need to do the same thing for backends/LTO since we'll need the TargetTuple to be serialized in the LLVM-IR to avoid information loss anyway.
> Fair enough.
I've left the paragraph about patching the constructor in for the moment but I've added a fixme indicating that it will be replaced by CMake/config-files asap. Is that ok for this patch?


http://reviews.llvm.org/D10969