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

[Eric Christopher]

Excellent. Thanks Daniel!

-eric

On Tue, Jul 7, 2015 at 1:58 PM Daniel Sanders <Daniel.Sanders at imgtec.com>
wrote:

> Ok, I'll post a write up of the problem(s) with GNU Triples and the
> planned solution in the morning.
> ________________________________________
> From: Renato Golin [renato.golin at linaro.org]
> Sent: 07 July 2015 20:04
> To: Daniel Sanders
> Cc: echristo at gmail.com; emaste at freebsd.org; jholewinski at nvidia.com;
> tberghammer at google.com; ted.woodward at codeaurora.org; jfb at chromium.org;
> llvm-commits at cs.uiuc.edu
> Subject: Re: [PATCH] D10969: Replace Triple with a new TargetTuple in
> MCTargetDesc/* and related. NFC.
>
> In http://reviews.llvm.org/D10969#200483, @echristo wrote:
>
> > Wait, can you give a rundown of what your TargetTuple is doing etc?
> Maybe a
> >  mail to the list? This seems weird.
>
>
> Hi Eric,
>
> This is an old project (5+ years) that is finally realising, and had many
> threads in the list (maybe not with "TargetTuple" in it). Daniel is working
> towards that goal for some good weeks now, but if you feel we need another
> round, I think we better have it. I want everyone to be on the same boat as
> we thread these dangerous waters.
>
> Maybe Daniel would be a better person to write up a summary of the changes
> so far and the plan for the future, as I was more focused on the
> TargetParser changes.
>
> cheers,
> --renato
>
>
> ================
> 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) {}
> ----------------
> 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.
>
> ================
> Comment at: include/llvm/ADT/TargetTuple.h:284
> @@ +283,3 @@
> +
> +  const std::string &getTriple() const { return GnuTT.str(); }
> +
> ----------------
> dsanders wrote:
> > rengolin wrote:
> > > why two?
> > At the moment, its just to preserve Triple's interface which had both.
> I've been rewriting instances of .getTriple() to .str() as I notice them.
> At some point, I'd like to rewrite the remainder and delete getTriple().
> >
> > Triple::getTriple() is fairly common, but it's also the least clear of
> the two. The name sounds like it ought to return 'this' :-)
> Ok.
>
>
> http://reviews.llvm.org/D10969
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20150707/caa4a8fe/attachment.html>