[LLVMdev] New TargetSpec 'llvmnote'

[Dan Gohman]

On Feb 22, 2011, at 6:46 PM, Chris Lattner wrote:
> This leads to a number of problems in LLVM:
>  - we have a bunch of duplication
>  - we have confusion about what a triple is (normalized or not)
>  - no good way to tell if a triple is normalized
>  - no good, centralized way to reason about which triples are allowed and valid
>  - the MC assembler has to link in the entire X86 backend to get subtarget info
>  - we don't have a good way to implement things like .code32 in the MC assembler
>  - LLDB replicates a lot of this code and heuristics
>  - we don't have good interfaces to inquire about the host
>  - we do std::string manipulation in llvm::Triple
>  - linux triples are actually quadruples!
>  - darwin tools that take -arch have to map them onto something internally.

Most of these are motivations for refactoring and code cleanup, but not
really for inventing a new target mini-language to replace triples.

The main problems with triples IMHO which motivate this are:

  - The vendor field is vague and non-orthoganal.
  - Triples don't represent subtarget attributes, except in the way that
    subtarget attributes are sometimes mangled into the architecture field
    in confusing ways.

At an initial read, the targetspec proposal's solutions to these
problems seem reasonable.

It's a little surprising to have a dedicated "Byte Order" field. One
possible reason for it is that mips.le.* is marginally nicer than
mipsel.*, however that's not obviously worth burdening everyone else
for. Another possible reason is to allow otherwise
architecture-independent strings to encode an endianness. However,
that's not a concept that LLVM currently has. And without more
targetdata parts, it's not obvious how useful it is by itself.

On the other hand, if "Byte Order" makes sense to include, should
other parts of targetdata be included? Pointer size seems the next
most desirable -- endianness and pointer size would be sufficient for
many elf tools, for example. However, the other parts of
targetdata could conceivably be useful too.

The "OS" field seems like it should be renamed to "ABI", since in the
description you discuss actual OS's that support multiple ABIs.

In the "Feature Delta" field, using "+" to add features but using
a charactar other than "-" to remove them is unfortunate. How about
just prohibiting "-" in CPU names? Or for another idea, how about
prefixing negative features with "no-", as in "core2+sse41+no-cmov"?

Dan

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20110223/b045a55e/attachment.html>