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
On Feb 23, 2011, at 3:24 PM, Stephen Wilson wrote:>> >> 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.I think that this can be reliably determined from the arch (through a predicate). x86-64 will always be 64-bit, x86 will always be 32-bit. Doing a "32-bit ABI in 64-bit mode" needs to be a new arch anyway, so that sort of thing isn't an issue IMO. To Dan's point, this argues for forcing a 1-1 mapping between arch and endianness, which would allow making endianness be a predicate instead of being an encoded part of the data structure. The *only* downside I see to that is that we couldn't form a TargetSpec that *just* contains an endianness, at least without introducing a "unknown-64bit" and "unknown-32bit" archspec, which seems silly. -Chris
On Wed, Feb 23, 2011 at 10:40:04PM -0800, Chris Lattner wrote:> > On Feb 23, 2011, at 3:24 PM, Stephen Wilson wrote: > > >> > >> 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. > > I think that this can be reliably determined from the arch (through a > predicate). x86-64 will always be 64-bit, x86 will always be 32-bit. > Doing a "32-bit ABI in 64-bit mode" needs to be a new arch anyway, so > that sort of thing isn't an issue IMO.Ya. You are right. The use case I was thinking of would probably be better addressed using mechanisms completely unrelated to TargetSpec.> To Dan's point, this argues for forcing a 1-1 mapping between arch and > endianness, which would allow making endianness be a predicate instead > of being an encoded part of the data structure. > > The *only* downside I see to that is that we couldn't form a > TargetSpec that *just* contains an endianness, at least without > introducing a "unknown-64bit" and "unknown-32bit" archspec, which > seems silly.Thinking about this a bit more, from an API point of view I agree. If we encode endianness as a fixed property of an arch then provided we have methods like "getLittleEndian("ppcbe") => "ppcle" then an "endian bit" is largely irrelevant -- the functionality is certainly equivalent and I think just as easy to use. Also, we will need something like that anyways to reason about GNU style tripples. However, one downside I can see is that we would effectively double the number of architectures (for the bi-endian case) by having a 1-1 mapping. The tables needed to model all cpu type, subtype and abi combos would be quite large even with the extra level of indirection an "endianness bit" gives us. So from an implementation point of view it seems to me like having an endian field would help here. Implementing a "setByteOrder" method might read like "is this arch bi-endian? If so flip the bit", as opposed to implementing (and maintaining) the tables needed to get specifically from the "armv5l" entry to "armv5b", etc, etc. And if that turns out to be true then embedding the endianness in a TargetSpec's string representation makes good sense (to me :). Perhaps I can find some time to get a rough code sketch together. Might be useful to experiment with a few different approaches. Thanks!> > -Chris-- steve