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

[Daniel Sanders via llvm-commits]

dsanders added a comment.

Thanks Renato.

> I don't expect it to clean up anything, since for now we're just moving things alone, but would be good to make Triple use the Tuple enums before deprecating it, so that you can remove a lot of code inserted by this patch.


We'd want to bring back separate enums eventually (see below) but if deferring that piece helps get the overall patch series moving then I don't mind doing that.

The reason for separating the enums is that it's desirable for Triple and TargetTuple to have different sets of values, particularly for ARM and Mips. By the end of the project, Triple's values should be focused on representing the triple, and TargetTuple's values should be focused on representing the target. For example, it's correct for mipsel-linux-gnu that Triple::getArch() returns Triple::mipsel. However, it's also desirable that TargetTuple::getArch() return TargetTuple::mips and TargetTuple::getEndian() return TargetTuple::LittleEndian. To put it another way, Triple's enum are more-or-less numeric representations of the input string, whereas TargetTuple's enums are representations of the intended target.

I don't know the ARM triples but here's an example based on what I've seen in your target parser work: Triple::getArch() should return Triple::armv7 for armv7-linux-gnu, while TargetTuple::getArch() would return TargetTuple::arm, and TargetTuple::getSubArch() would return TargetTuple::v7. Does that agree with your understanding of ARM triples?

From Eric's comment:

> I'm sorry for all the delays, I'm trying to get back to this and haven't forgotten it (or the other thread). My apologies.


I don't want to pressure you as I know you're busy but could you be a little more specific than that? My biggest worry is that the issues this project resolves are blocking our toolchain products and while the schedule for some of those feels like a long time, I'm also concious of the fact that sorting these issues out is a multi-month project.


http://reviews.llvm.org/D10969