On Feb 23, 2011, at 2:47 AM, David Given wrote:> On 02/23/11 02:46, Chris Lattner wrote: > [...] >> Remember that this isn't intended to be something users deal with, it's just an internal implementation detail of the compiler, debugger, nm implementation, etc. > > Can I put in a plea to have as much of LLVM as possible *not* require > knowledge of a single, specific architecture to work? > > I have various things I would like to do that work on abstract machines, > where I don't have a specific target or CPU in mind, but just want to > work at the bitcode level. Right now the only way I know of doing this > is to hardcode the datalayout into a new target and rebuild the whole > shooting match, LLVM and clang combined. I very much do not want to do this.This request is completely orthogonal to the proposal. If you generate target independent LLVM IR, you don't have to put a triple into the IR. This isn't going to change. -Chris
On 23/02/11 19:26, Chris Lattner wrote: [...]> This request is completely orthogonal to the proposal. If you generate target independent LLVM IR, you don't have to put a triple into the IR. This isn't going to change.Unfortunately clang doesn't appear to be aware of this. It's forcing me to specify a triple (or at least, I haven't discovered a way of generating target-independent IR with it yet). If I want to, say, generate code where ints are 64 bits but have a 32 bit alignment, as far as I know I have to go create a custom target and rebuild everything. If this is purely a clang issue which doesn't extend to the rest of LLVM that's fine and I'll bring it up with them, but nevertheless I feel that hardcoding this kind of information into the target is a bit restrictive. For example: the proposal mentions storing information as enums. This means that if I want a target with a feature that TargetSpec doesn't know about, my choices are to either pick 'unknown' or else add it to the enum table and then rebuild everything. Given that the actual values of the enums are arbitrary and hidden, they should just be an implementation detail. An alternative implementation would be to keep a map of feature tokens and dynamically assign new values as necessary. This means that it would be possible for TargetSpec to parse "fnord.le.linux.elf.with-baz" even though TargetSpec knows nothing about the 'fnord' architecture. This would then allow custom passes which *do* know what a fnord is to be able to reason about the feature information. -- ┌─── ｄｇ＠ｃｏｗｌａｒｋ．ｃｏｍ ───── http://www.cowlark.com ───── │ │ "I have a mind like a steel trap. It's rusty and full of dead mice." │ --- Anonymous, on rasfc -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 254 bytes Desc: OpenPGP digital signature URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20110223/9fce314a/attachment.sig>
> Unfortunately clang doesn't appear to be aware of this. It's forcing me > to specify a triple (or at least, I haven't discovered a way of > generating target-independent IR with it yet). If I want to, say, > generate code where ints are 64 bits but have a 32 bit alignment, as far > as I know I have to go create a custom target and rebuild everything.You cannot generate platform-independent IR out of C. See http://llvm.org/docs/FAQ.html#platformindependent for more info -- With best regards, Anton Korobeynikov Faculty of Mathematics and Mechanics, Saint Petersburg State University