[llvm-dev] The Trouble with Triples

[Daniel Sanders via llvm-dev]

> > Right now I see TargetTuple as trying to take over all of the various
> > arguments to TargetMachine and encapsulate them into a single thing. I
> also
> > don't see this is bad, but I also don't see it taking all of them right now
> > and I'm not sure how it solves some of the existing problems with data
> > sharing that we've got which is where the push back you're both getting is
> > coming from here.
> 
> From my understanding, there are two separate worlds: the precise and
> unambiguous world of target descriptions, and the chaotic world of
> command line options.
> 
> Command line options are often ambiguous, they interact with each
> other and they can change according to the host-target relationship.
> Parsing all this knowledge and disambiguating it is not a simple task.
> It requires a lot of code, a lot of parsing, a lot of switches and
> mappings between enums. But once this is done, a low-level unique
> representation can be achieved.
> 
> On the other hand, the class that is tasked to hold all the
> information of all targets in an orderly and unique fashion has to be
> precise and correct above all else. There's no space for doubt or
> guess work in such a class, or the compiler will start taking random
> decisions and it'd be a nightmare to understand it.
> 
> So it is clear to me that these two concepts should never cross wires.
> In the same way that the Tuple shouldn't be parsing target-specific
> stuff on its own, I don't think that a precise machine representation
> should be cross-referencing user options to define its properties.

That's exactly right.