[LLVMdev] New TargetSpec 'llvmnote'

[Stephen Wilson]

On Wed, Feb 23, 2011 at 01:43:35PM -0800, Dan Gohman wrote:
> 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.

In LLDB we currently have an "ArchSpec" class that llvm::TargetSpec
could eventually replace.  Currently, one of the main applications for
having a "byte order" bit in LLDB is to allow sensible construction of
default specifications:  for example ARM is almost always little endian,
but there are board configurations where this is not the case.  I think
with sensible default values most people will not find the extra flag a
burden.

Having a byte order bit just helps model bi-endian architectures that
much more accurately IMHO.  For example, it would help when implementing
support for debugging boot code that forces the processor to switch
modes (PowerPC for example).


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

Possibly useful again from an LLDB perspective.  I could imagine
debugging x86_64 operating system code and needing a way to communicate
transitions from 64-bit mode and 32-bit compatibility mode seamlessly.
However, I must stress this is *possibly* useful -- I do not have a firm
conclusion to offer here.   Perhaps this is something that we could
support on an as needed basis.

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

> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev


-- 
steve