[LLVMdev] RFC: MCJIT enhancements

[Paweł Bylica]

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.

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ł
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20120817/9be1d735/attachment.html>