search for: targetspec

This is about the target specification proposal described in http://nondot.org/sabre/LLVMNotes/TargetSpec.txt At the end of the year I spent a while on this, partly as a foot-wetting exercise for parts of LLVM I wouldn't otherwise look at. I did a partial implementation; enough to understand most of the issues (I hope) and get a clear idea of what would need to be done to phase it in. I expect to...

The simplest solution is probably to just break it out into its own library. -- Sean Silva -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130213/9ab171c0/attachment.html>

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

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

...lot to be desired.  GNU target triples are really important as input devices to the compiler (users want to specify them) but they aren't detailed enough for internal clients. > > Anyway, in short, I think that we should unify the variety of code we have to deal with this stuff into a new TargetSpec class.   I don't have any short-term plan to implement this, but I wrote up some of my thoughts here: > http://nondot.org/sabre/LLVMNotes/TargetSpec.txt > > Remember that this isn't intended to be something users deal with, it's just an internal implementation detail of the com...

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

...leave a lot to be desired. GNU target triples are really important as input devices to the compiler (users want to specify them) but they aren't detailed enough for internal clients. Anyway, in short, I think that we should unify the variety of code we have to deal with this stuff into a new TargetSpec class. I don't have any short-term plan to implement this, but I wrote up some of my thoughts here: http://nondot.org/sabre/LLVMNotes/TargetSpec.txt Remember that this isn't intended to be something users deal with, it's just an internal implementation detail of the compiler, debugge...

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

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

...e manageable) and Micah's support, I received no reply on this. Does there exist a way to tell MC to generate and ELF container for code on Windows? If not, I'm willing to submit a patch to fix this, but would like some opinions on the best direction to take here. The proposed "llvm::TargetSpec class" (http://nondot.org/sabre/LLVMNotes/TargetSpec.txt) seems to address this, although AFAICS the current llvm::Triple does not explicitly specify the object/container type. ELF is usually taken as "default" when no other option is chosen. A representative example from X86MCTarget...

...e manageable) and Micah's support, I received no reply on this. Does there exist a way to tell MC to generate and ELF container for code on Windows? If not, I'm willing to submit a patch to fix this, but would like some opinions on the best direction to take here. The proposed "llvm::TargetSpec class" (http://nondot.org/sabre/LLVMNotes/TargetSpec.txt) seems to address this, although AFAICS the current llvm::Triple does not explicitly specify the object/container type. ELF is usually taken as "default" when no other option is chosen. A representative example from X86MCTarget...

Hello, We're currently working on MC-JIT, focusing on runtime generation and loading of ELF object files, even on non-ELF platforms (i.e. Windows). However, we run into a problem with MC insisting to generate COFF objects on Windows, MachO on Macs and ELF only otherwise, based on the triple. Is there an existing method to generate ELF objects with MC on Windows, without modifying MC? Thanks

...rly well designed, and don't capture the information we really need. Instead of adding another component to triple, I think it would be interesting to finally tackle the big redesign of this area. For example, something along these lines might be interesting: http://nondot.org/sabre/LLVMNotes/TargetSpec.txt -Chris > > -Jim > > On Sep 4, 2012, at 5:21 PM, "Kaylor, Andrew" <andrew.kaylor at intel.com> wrote: > >> ping >> >> From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Kaylor, Andrew >> Sent: T...

...rly well designed, and don't capture the information we really need. Instead of adding another component to triple, I think it would be interesting to finally tackle the big redesign of this area. For example, something along these lines might be interesting: http://nondot.org/sabre/LLVMNotes/TargetSpec.txt -Chris -Jim On Sep 4, 2012, at 5:21 PM, "Kaylor, Andrew" <andrew.kaylor at intel.com<mailto:andrew.kaylor at intel.com>> wrote: ping From: llvmdev-bounces at cs.uiuc.edu<mailto:llvmdev-bounces at cs.uiuc.edu> [mailto:llvmdev-bounces at cs.uiuc.edu<mailto:...

Chris, are you OK with the below changes to the Triple? -Jim On Sep 4, 2012, at 5:21 PM, "Kaylor, Andrew" <andrew.kaylor at intel.com> wrote: > ping > > From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Kaylor, Andrew > Sent: Tuesday, August 28, 2012 11:10 AM > To: Jim Grosbach; Pawel Bylica; Chris Lattner > Cc: llvmdev

ping From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Kaylor, Andrew Sent: Tuesday, August 28, 2012 11:10 AM To: Jim Grosbach; Pawel Bylica; Chris Lattner Cc: llvmdev at cs.uiuc.edu (LLVMdev at cs.uiuc.edu) Subject: Re: [LLVMdev] RFC: MCJIT enhancements Has anything more happened with this? -Andy From: Jim Grosbach [mailto:grosbach at apple.com] Sent: