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: Friday, August 17, 2012 7:51 AM To: Paweł Bylica; Chris Lattner Cc: llvmdev at cs.uiuc.edu<mailto:llvmdev at cs.uiuc.edu> (LLVMdev at cs.uiuc.edu<mailto:LLVMdev at cs.uiuc.edu>); Kaylor, Andrew Subject: Re: [LLVMdev] RFC: MCJIT enhancements On Aug 17, 2012, at 2:50 AM, Paweł Bylica <pawel.bylica at ibs.org.pl<mailto:pawel.bylica at ibs.org.pl>> wrote: On Fri, Aug 17, 2012 at 12:16 AM, Kaylor, Andrew <andrew.kaylor at intel.com<mailto:andrew.kaylor at intel.com>> wrote: Hi Paweł, Thanks for continuing this discussion. I like the simplicity of your suggestion. My only concern involves the ambiguity of what is meant by “environment”. Presently there are functions in the llvm::Triple class to access the environment as an enumeration of a fixed set of values. It seems that some non-enumerated values are already in use, but introducing possible combinations of ABI and object format would seem to strain the API. I couldn’t find an explanation anywhere of what is meant by environment in the context of the triple, and it isn’t clear from looking at the possible values whether object format properly belongs to the environment concept or whether it should be a new triple component. Looking at the uses in the LLVM code base, it seems that the environment element has been used specifically to enable generation of MachO objects on non-Darwin OSes. I see that clang recognizes “iphoneos” as a value (though it’s not in the Triple::EnvironmentType enum), and it’s not clear to me what it uses it for. Beyond that, the environment seems to be used to influence ABI selection, which would seem to have some degree of overlap with object format selection while being essentially different. In other words, environment seems to be a bit of a catch-all dumping ground at the moment. That’s not entirely bad, I suppose, but it does make the task of cleanly extending the target triple more complicated. It would seem that at some point the target triple has evolved into a target quadruple with the addition of environment. The question now, I think, is whether it makes sense to extend it further into a target quintuple, adding object format as a well-defined, but optional, component with full API support. The difficulty, of course, is that with two optional extensions the expected canonical form becomes ambiguous, but I don’t think that’s much of a problem. Given that object format is a relatively small enumeration, the triple parser should be able to handle it presence or absence while parsing or normalizing. So here’s what I would suggest. 1. Define the target triple as follows (adapted from Triple.h): /// Target triples are strings in the canonical form: /// ARCHITECTURE-VENDOR-OPERATING_SYSTEM /// or /// ARCHITECTURE-VENDOR-OPERATING_SYSTEM-OBJECT_FORMAT /// or /// ARCHITECTURE-VENDOR-OPERATING_SYSTEM-ENVIRONMENT /// or /// ARCHITECTURE-VENDOR-OPERATING_SYSTEM-OBJECT_FORMAT-ENVIRONMENT 2. Add an llvm::Triple::ObjectFormatType enum with all llvm-supported object formats. 3. Remove “MachO” from the llvm::Triple::EnvironmentType enum. 4. Add the following methods to llvm::Triple: Triple(const Twine &ArchStr, const Twine &VendorStr, const Twine &OSStr, const Twine &ObjFmtStr) Triple(const Twine &ArchStr, const Twine &VendorStr, const Twine &OSStr, const Twine &ObjFmtStr, const Twine &EnvStr) bool hasExplicitObjectFormat() const ObjectFormatType getObjectFormat() const StringRef getObjectFormatName() const bool isOutputObjectFormatELF() const bool isOutputObjectFormatCOFF() const bool isOutputObjectFormatMachO() const static const char * getObjectFormatName(ObjectFormatType Kind) 5. When an object format is specified, it will be used by MC and MCJIT if supported for the specified architecture 6. When an unsupport object format is specified, a fatal error will be thrown 7. When an object format and environment are both specified but are incompatible, a fatal error will be thrown 8. When an object format is not specified everything will behave as it currently does How does that sound? -Andy Hi Andy, That sounds great. Do we need any approval for this change? I can do the coding I you don't mind. Changes to the Triple have pretty wide-reaching implications. Chris, what do you think? -Jim I have one more question. Triples are specified in both modules and TargetMachine. In 3.1 triple from module was used by default. In trunk it has been changed, and LLVM_HOSTTRIPLE is used by default. Do we have any rules in case module triple conflicts with TargetMachine triple? - Paweł _______________________________________________ LLVM Developers mailing list LLVMdev at cs.uiuc.edu<mailto:LLVMdev at cs.uiuc.edu> http://llvm.cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20120905/f410bcb9/attachment.html>
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 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: Friday, August 17, 2012 7:51 AM > To: Paweł Bylica; Chris Lattner > Cc: llvmdev at cs.uiuc.edu (LLVMdev at cs.uiuc.edu); Kaylor, Andrew > Subject: Re: [LLVMdev] RFC: MCJIT enhancements > > > On Aug 17, 2012, at 2:50 AM, Paweł Bylica <pawel.bylica at ibs.org.pl> wrote: > > > On Fri, Aug 17, 2012 at 12:16 AM, Kaylor, Andrew <andrew.kaylor at intel.com> wrote: > Hi Paweł, > > Thanks for continuing this discussion. > > I like the simplicity of your suggestion. My only concern involves the ambiguity of what is meant by “environment”. Presently there are functions in the llvm::Triple class to access the environment as an enumeration of a fixed set of values. It seems that some non-enumerated values are already in use, but introducing possible combinations of ABI and object format would seem to strain the API. > > I couldn’t find an explanation anywhere of what is meant by environment in the context of the triple, and it isn’t clear from looking at the possible values whether object format properly belongs to the environment concept or whether it should be a new triple component. Looking at the uses in the LLVM code base, it seems that the environment element has been used specifically to enable generation of MachO objects on non-Darwin OSes. I see that clang recognizes “iphoneos” as a value (though it’s not in the Triple::EnvironmentType enum), and it’s not clear to me what it uses it for. Beyond that, the environment seems to be used to influence ABI selection, which would seem to have some degree of overlap with object format selection while being essentially different. > > In other words, environment seems to be a bit of a catch-all dumping ground at the moment. That’s not entirely bad, I suppose, but it does make the task of cleanly extending the target triple more complicated. > > It would seem that at some point the target triple has evolved into a target quadruple with the addition of environment. The question now, I think, is whether it makes sense to extend it further into a target quintuple, adding object format as a well-defined, but optional, component with full API support. The difficulty, of course, is that with two optional extensions the expected canonical form becomes ambiguous, but I don’t think that’s much of a problem. Given that object format is a relatively small enumeration, the triple parser should be able to handle it presence or absence while parsing or normalizing. > > So here’s what I would suggest. > > 1. Define the target triple as follows (adapted from Triple.h): > > > > /// Target triples are strings in the canonical form: > > /// ARCHITECTURE-VENDOR-OPERATING_SYSTEM > > /// or > > /// ARCHITECTURE-VENDOR-OPERATING_SYSTEM-OBJECT_FORMAT > > /// or > > /// ARCHITECTURE-VENDOR-OPERATING_SYSTEM-ENVIRONMENT > > /// or > > /// ARCHITECTURE-VENDOR-OPERATING_SYSTEM-OBJECT_FORMAT-ENVIRONMENT > > > > 2. Add an llvm::Triple::ObjectFormatType enum with all llvm-supported object formats. > > 3. Remove “MachO” from the llvm::Triple::EnvironmentType enum. > > 4. Add the following methods to llvm::Triple: > > > > Triple(const Twine &ArchStr, const Twine &VendorStr, const Twine &OSStr, const Twine &ObjFmtStr) > > Triple(const Twine &ArchStr, const Twine &VendorStr, const Twine &OSStr, const Twine &ObjFmtStr, const Twine &EnvStr) > > bool hasExplicitObjectFormat() const > > ObjectFormatType getObjectFormat() const > > StringRef getObjectFormatName() const > > bool isOutputObjectFormatELF() const > > bool isOutputObjectFormatCOFF() const > > bool isOutputObjectFormatMachO() const > > static const char * getObjectFormatName(ObjectFormatType Kind) > > > > 5. When an object format is specified, it will be used by MC and MCJIT if supported for the specified architecture > > 6. When an unsupport object format is specified, a fatal error will be thrown > > 7. When an object format and environment are both specified but are incompatible, a fatal error will be thrown > > 8. When an object format is not specified everything will behave as it currently does > > > How does that sound? > > -Andy > > Hi Andy, > > That sounds great. Do we need any approval for this change? I can do the coding I you don't mind. > > > Changes to the Triple have pretty wide-reaching implications. Chris, what do you think? > > -Jim > > > I have one more question. Triples are specified in both modules and TargetMachine. In 3.1 triple from module was used by default. In trunk it has been changed, and LLVM_HOSTTRIPLE is used by default. Do we have any rules in case module triple conflicts with TargetMachine triple? > > - Paweł > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20120904/8d680e38/attachment.html>
On Sep 4, 2012, at 5:23 PM, Jim Grosbach <grosbach at apple.com> wrote:> Chris, are you OK with the below changes to the Triple?If at all possible, I'd like to keep the triple changes separate (separate patch series and separate discussion) from the other MCJIT changes. How dependent are the MCJIT improvements on the Triple changes? As you've noticed, Triple is not a particularly well defined class, because it is heavily influenced by the GNU target triples, which are themselves not particularly 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: 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: Friday, August 17, 2012 7:51 AM >> To: Paweł Bylica; Chris Lattner >> Cc: llvmdev at cs.uiuc.edu (LLVMdev at cs.uiuc.edu); Kaylor, Andrew >> Subject: Re: [LLVMdev] RFC: MCJIT enhancements >> >> >> On Aug 17, 2012, at 2:50 AM, Paweł Bylica <pawel.bylica at ibs.org.pl> wrote: >> >> >> On Fri, Aug 17, 2012 at 12:16 AM, Kaylor, Andrew <andrew.kaylor at intel.com> wrote: >> Hi Paweł, >> >> Thanks for continuing this discussion. >> >> I like the simplicity of your suggestion. My only concern involves the ambiguity of what is meant by “environment”. Presently there are functions in the llvm::Triple class to access the environment as an enumeration of a fixed set of values. It seems that some non-enumerated values are already in use, but introducing possible combinations of ABI and object format would seem to strain the API. >> >> I couldn’t find an explanation anywhere of what is meant by environment in the context of the triple, and it isn’t clear from looking at the possible values whether object format properly belongs to the environment concept or whether it should be a new triple component. Looking at the uses in the LLVM code base, it seems that the environment element has been used specifically to enable generation of MachO objects on non-Darwin OSes. I see that clang recognizes “iphoneos” as a value (though it’s not in the Triple::EnvironmentType enum), and it’s not clear to me what it uses it for. Beyond that, the environment seems to be used to influence ABI selection, which would seem to have some degree of overlap with object format selection while being essentially different. >> >> In other words, environment seems to be a bit of a catch-all dumping ground at the moment. That’s not entirely bad, I suppose, but it does make the task of cleanly extending the target triple more complicated. >> >> It would seem that at some point the target triple has evolved into a target quadruple with the addition of environment. The question now, I think, is whether it makes sense to extend it further into a target quintuple, adding object format as a well-defined, but optional, component with full API support. The difficulty, of course, is that with two optional extensions the expected canonical form becomes ambiguous, but I don’t think that’s much of a problem. Given that object format is a relatively small enumeration, the triple parser should be able to handle it presence or absence while parsing or normalizing. >> >> So here’s what I would suggest. >> >> 1. Define the target triple as follows (adapted from Triple.h): >> >> >> >> /// Target triples are strings in the canonical form: >> >> /// ARCHITECTURE-VENDOR-OPERATING_SYSTEM >> >> /// or >> >> /// ARCHITECTURE-VENDOR-OPERATING_SYSTEM-OBJECT_FORMAT >> >> /// or >> >> /// ARCHITECTURE-VENDOR-OPERATING_SYSTEM-ENVIRONMENT >> >> /// or >> >> /// ARCHITECTURE-VENDOR-OPERATING_SYSTEM-OBJECT_FORMAT-ENVIRONMENT >> >> >> >> 2. Add an llvm::Triple::ObjectFormatType enum with all llvm-supported object formats. >> >> 3. Remove “MachO” from the llvm::Triple::EnvironmentType enum. >> >> 4. Add the following methods to llvm::Triple: >> >> >> >> Triple(const Twine &ArchStr, const Twine &VendorStr, const Twine &OSStr, const Twine &ObjFmtStr) >> >> Triple(const Twine &ArchStr, const Twine &VendorStr, const Twine &OSStr, const Twine &ObjFmtStr, const Twine &EnvStr) >> >> bool hasExplicitObjectFormat() const >> >> ObjectFormatType getObjectFormat() const >> >> StringRef getObjectFormatName() const >> >> bool isOutputObjectFormatELF() const >> >> bool isOutputObjectFormatCOFF() const >> >> bool isOutputObjectFormatMachO() const >> >> static const char * getObjectFormatName(ObjectFormatType Kind) >> >> >> >> 5. When an object format is specified, it will be used by MC and MCJIT if supported for the specified architecture >> >> 6. When an unsupport object format is specified, a fatal error will be thrown >> >> 7. When an object format and environment are both specified but are incompatible, a fatal error will be thrown >> >> 8. When an object format is not specified everything will behave as it currently does >> >> >> How does that sound? >> >> -Andy >> >> Hi Andy, >> >> That sounds great. Do we need any approval for this change? I can do the coding I you don't mind. >> >> >> Changes to the Triple have pretty wide-reaching implications. Chris, what do you think? >> >> -Jim >> >> >> I have one more question. Triples are specified in both modules and TargetMachine. In 3.1 triple from module was used by default. In trunk it has been changed, and LLVM_HOSTTRIPLE is used by default. Do we have any rules in case module triple conflicts with TargetMachine triple? >> >> - Paweł >> _______________________________________________ >> LLVM Developers mailing list >> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20120907/1c8beb37/attachment.html>