[LLVMdev] New TargetSpec 'llvmnote'

David Given dg at cowlark.com
Wed Feb 23 13:24:38 PST 2011


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.

-- 
┌─── dg@cowlark.com ───── 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>


More information about the llvm-dev mailing list