[llvm-dev] The Trouble with Triples

[Renato Golin via llvm-dev]

On 24 September 2015 at 06:18, Daniel Sanders <Daniel.Sanders at imgtec.com> wrote:
> Additionally, Renato wants this separation because interpreting ARM triples
> is hard and he needs somewhere to store the interpreted meaning.

I have two main problems:

1. Parsing all the numerous options, not just triples, is slow and
should only ever be done once. However we do the passing of
information to the back-end, it has to be in a way that passes and
codegen classes can query to understand about the target. I believe
TargetMachine and friends can do that, we just have to make sure that
*all* knowledge is accessible via those classes.

2. CPU names can change the Arch name and vice-versa, and we had
numerous problems of things disappearing and all moving back to
armv4t. That used to happen because at different stages of the driver,
the string parsing routines would fail and return null or empty
strings, and the rest of the driver couldn't cope with it.

Moving all parsing into one location (TargetParser) was the first
step, but all places that used to do string parsing are still calling
those methods, which means we're not that much better off. If we move
all parsing *usage* into one location and only deal with enum values,
not only it'll be a lot faster, but we would be able to reason about
every convoluted option in less, bigger methods, reducing the
opportunity for bad assumptions.

We still need the parser in the back-end, though, as assembler options
use the same syntax and generally mean the same thing, so we need to
make it safe to use it to change the TargetMachine while assembling.

None of this goes against any of what you guys are discussing, I
believe, I just wanted to make it clear what my issues were. :)

cheers,
--renato