[LLVMdev] New TargetSpec 'llvmnote'

[Chris Lattner]

On Feb 23, 2011, at 1:43 PM, Dan Gohman wrote:
> Most of these are motivations for refactoring and code cleanup, but not
> really for inventing a new target mini-language to replace triples.

That's all I'm proposing.  I'm not suggesting that the "mini language" be exposed to users, it's just a "serialized for an internal-to-llvm clients" data structure.  The string form would be persisted in .ll and .bc files, that's all. 

> 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.

It is useful for doing simple queries about the target, and these are things that can be derived from .o files.

> 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.

I could be convinced about this.  The other approach would be to formalize this as part of the arch spec and treat mips and mips-le as two different arches, and have a predicate that generates the bit on demand.

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

It's really a cross product of OS's and ABIs.  For example, darwin10 vs darwin9 is not an ABI, it is an OS.  I consider linux-eabi to be different than linux-someotherabi because the entire OS has to be build that way.  *shrug*

> 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"?

Good idea! I changed it to use commas and "no", giving "core2,sse41,nocmov".

-Chris