[LLVMdev] The Trouble with Triples

[Renato Golin]

On 30 July 2015 at 07:51, Eric Christopher <echristo at gmail.com> wrote:
> This is pretty vague.

Let em give you one concrete example where I want to use the TargetTuple.

Today, we parse the triple into a Triple object. Then, we parse all
command lines, and add special -target-feature flags. This logic is
duplicated for all tools that accept the same command line options,
because there isn't a single source of information.

My first step was to create the TargetParser, which does the string
parsing, resolving to legal internal representations, that can be use
to not only validate, but also transfer knowledge to other classes,
like TargetTuple, about what the target is. As it stands, TargetParser
has a variable internal representation (enums and tables, that will be
generated by tablegen later), so it's not safe to rely on them between
revisions, but it's ok because no one is. We now use that class to
parse Clang's options, assembler directives, etc.

My first goal with the TargetTuple is to build it with a Triple (which
also uses TargetParser to parse the architecture part), and then let
all methods I'm currently keeping on TargetParser to set the feature
flags. Once that's done, we can start adding a more stable API and use
methods for the most common/important flags (such as hasVFP(),
isARMv7(), etc) and let the accessors return the internal unreliable
value for direct comparisons using the enum values.

Ex:
  if (Tuple.getCPUFeatures() & ARM::HWDIV) // has hardware divide.

That should not be used to build TargetMachine and others, but just
for local enquiries, and possibly not all of it should be exposed.
That's why I want to have separate (maybe redundant) ways: direct
access to const values, and accessor methods for what's *really*
public.

>From there, it should be straightforward to have a simple method:

  Tuple.getTargetFeatures(Features);

which will expose every thing that Clang does today, based on its own
string parsing. Once that's done, than Clang will just need to know
what kind of argument goes into what kind of field:

  const Arg *CPUArg = Args.getLastArg(options::OPT_mcpu_EQ);
  Tuple.setCPU(CPUArg);
  const Arg *FPUArg = Args.getLastArg(options::OPT_mfpu_EQ);
  Tuple.setFPU(FPUArg);

since Tuple depends on the architecture, setting CPU, FPU, Extensions
should use the arch-specific parser, which will use arch-specific
Tuple.setFeatures() -> Tuple.setARMFeatures() after setting the CPU,
FPU, etc.


> My first impression of using this serialization as is that it's something
> I'm against. Keep in mind that being able to parse the string can't invoke a
> target backend to handle the rest of the parsing. It'd need to be as generic
> as a DataLayout if you want to do this sort of thing and I'm entirely
> uncertain this is possible for the goals you (and I) have in mind here.

I'm ok with adding a condensed extra argument with some key target
features. Changing the triple will disrupt too much of the past, and
goes back to the mud ripples effect we were talking earlier.

But even that features string has to be small, condensed, and will
never represent everything. We should not expect that we can encode
every bit of information, nor should we strive to put as much as
possible.

We have to assume that the user will pass the same arguments to llc,
lli, llvm-mc and other tools as (s)he passed to clang. If the command
line parsing (at least the target-specific part) is common, than we
won't even need the extra features field.



> Let me be clear, I do agree with you that the Triple by itself is
> insufficient for what we want long term in the backends, however, we won't
> be able to get rid of it completely. It's too ingrained into how cross
> compilation is done as a base.

Precisely.


> My vision for this is an API that has a base part that is
> going to be generic across all targets (think the current arguments to the
> TargetMachine constructor), and additional target specific information that
> can be passed in via user customization (i.e. command line options etc).

That's how I see it, too.

cheers,
--renato