Hi, Lang. Thanks for clarification. I will check out current branch tomorrow and report you back. Most likely i will create bug issue with cleaned sources for static lib and test ios app. Actually i'm not professional c++ dev so my question is - is there any chance to do the next: 1. compile .cpp code to .ll code (seems i already did it) 2. interpret .ll file by any supported at the moment way (i'm not sure if this can be done without relocations or smth like that)? I will do my best to assist you and i can test as soon as new commits are coming. Regards, Anton. 2014-09-18 23:00 GMT+06:00 Lang Hames <lhames at gmail.com>:> Hi Anton, > > Could you file a bug with your source and build scripts at llvm.org/bugs > and CC me on it? > > As Tim mentioned the old JIT was not well maintained in 3.4/3.5, and has > been removed from LLVM's mainline. Unfortunately MCJIT's support for > MachO/ARM didn't received much attention until recently either - MachO ARM > relocations are totally broken in 3.5, so any symbolic references in the > final object file (E.g. for @.str in your example) will lead to failures. > > I would recommend trying MCJIT with the current development branch of LLVM > - you will probably have more luck there. > > Don't hesitate to file bugs for any issues you run in to on the > development branch - the more test cases we have the easier it will be to > get MachO/ARM fully supported in MCJIT. > > Regards, > Lang. > > > On Wed, Sep 17, 2014 at 12:11 PM, Anton Smirnov <dev at antonsmirnov.name> > wrote: > >> I've also tried the next combination: >> true, // ForceInterpreter >> false, // UseMCJIT >> and ios app just crashed with no output >> >> 2014-09-18 0:47 GMT+06:00 Anton Smirnov <dev at antonsmirnov.name>: >> >>> Hey. >>> >>> I've checked out LLVM/Clang 3.5 and modified my static libs source code >>> to use the latest llvm/clang sources. >>> Also i'm trying triple ""arm64-apple-ios7.0"" now as it's wriiten in 3.5 >>> release notes. >>> >>> I'm having simple (and pretty useless) source file: >>> int main(int count, const char **args) { >>> const char *c = "hello world"; >>> return 1 + 5; >>> } >>> >>> i using the next llc params: >>> const char *cmd[] = { >>> "clang", >>> "-cc1", >>> "-triple", >>> "arm64-apple-ios7.0", >>> "-emit-llvm", >>> "-disable-free", >>> "-main-file-name", >>> [cppShortFile UTF8String], // "hw.cpp" >>> "-mrelocation-model", >>> "pic", >>> "-pic-level", >>> "2", >>> "-mdisable-fp-elim", >>> "-masm-verbose", >>> "-target-linker-version", >>> "236.3", >>> "-v", >>> "-coverage-file", >>> [llFile UTF8String], >>> //"/private/var/mobile/Applications/175ECA7F-3175-4AC9-971C-85272F5492C4/tmp/hw.ll" >>> "-resource-dir", >>> [[[ASPathHolder sharedHolder] tempFolder] UTF8String], >>> "-stdlib=libc++", >>> "-fdeprecated-macro", >>> "-fdebug-compilation-dir", >>> [[[ASPathHolder sharedHolder] tempFolder] UTF8String], >>> "-ferror-limit", >>> "19", >>> "-fmessage-length", >>> "0", >>> "-stack-protector", >>> "1", >>> "-mstackrealign", >>> "-fcxx-exceptions", >>> "-fexceptions", >>> "-fdiagnostics-show-option", >>> "-vectorize-slp", >>> "-mfloat-abi", >>> "soft", >>> "-o", >>> [llFile UTF8String], // >>> /private/var/mobile/Applications/175ECA7F-3175-4AC9-971C-85272F5492C4/tmp/hw.ll >>> "-x", >>> "c++", >>> [cppFile UTF8String] >>> //"/private/var/mobile/Applications/175ECA7F-3175-4AC9-971C-85272F5492C4/tmp/hw.cpp" >>> }; >>> >>> and i'm getting the next .ll code (which seems to be pretty close or >>> exactly the same as previous one): >>> ; ModuleID >>> '/var/mobile/Applications/53D60D11-DF93-4129-AD97-B96424D165B5/Documents/projects/calc/calc.cpp' >>> target datalayout = "e-m:o-i64:64-i128:128-n32:64-S128" >>> target triple = "arm64-apple-ios7.0" >>> >>> @.str = private unnamed_addr constant [12 x i8] c"hello world\00", align >>> 1 >>> >>> ; Function Attrs: nounwind ssp >>> define i32 @main(i32 %count, i8** %args) #0 { >>> entry: >>> %retval = alloca i32, align 4 >>> %count.addr = alloca i32, align 4 >>> %args.addr = alloca i8**, align 8 >>> %c = alloca i8*, align 8 >>> store i32 0, i32* %retval >>> store i32 %count, i32* %count.addr, align 4 >>> store i8** %args, i8*** %args.addr, align 8 >>> store i8* getelementptr inbounds ([12 x i8]* @.str, i32 0, i32 0), >>> i8** %c, align 8 >>> ret i32 6 >>> } >>> >>> attributes #0 = { nounwind ssp "less-precise-fpmad"="false" >>> "no-frame-pointer-elim"="true" "no-frame-pointer-elim-non-leaf" >>> "no-infs-fp-math"="false" "no-nans-fp-math"="false" >>> "stack-protector-buffer-size"="8" "unsafe-fp-math"="false" >>> "use-soft-float"="false" } >>> >>> !llvm.ident = !{!0} >>> >>> !0 = metadata !{metadata !"clang version 3.5.0 (tags/RELEASE_350/final >>> 217949)"} >>> >>> (Note changed triple and compiler version. Also note i'm not using >>> "target-cpu" argument now as "cortex-a8" is not supported for this triple). >>> >>> Next i'm trying to interpret it (source code is copy-pasted from lli >>> tool source code): >>> >>> // lli with my default arguments >>> int llvm_interpret(const char *ll_filename) { >>> std::string InputFile(ll_filename); >>> >>> return llvm_interpret( >>> InputFile, >>> std::vector<std::string>(), // argv >>> false, // ForceInterpreter >>> false, // UseMCJIT >>> false, // DebugIR >>> false, // RemoteMCJIT >>> "", // ChildExecPath >>> ' ', // OptLevel >>> std::string("arm64-apple-ios7.0"), // TargetTriple >>> std::string("arm64"), // MArch >>> std::string(), // MCPU >>> std::vector<std::string>(), // MAttrs >>> "main", // EntryFunc >>> std::vector<std::string>(), // ExtraModules >>> std::vector<std::string>(), // ExtraObjects >>> std::vector<std::string>(), // ExtraArchives >>> false, // EnableCacheManager >>> std::string(), // ObjectCacheDir >>> std::string(), // FakeArgv0 >>> false, // DisableCoreFiles >>> false, // NoLazyCompilation >>> Reloc::PIC_, // RelocModel >>> CodeModel::JITDefault, // CMModel >>> true, // GenerateSoftFloatCalls >>> FloatABI::Soft, // FloatABIForCalls >>> false, // EmitJitDebugInfo >>> false // EmitJitDebugInfoToDisk >>> ); >>> >>> I'm getting the next error text: >>> *error creating EE: target does not support JIT code generation* >>> >>> Ok, let's try using MCJIT as i was suggested. >>> Now change default value for "UseMCJIT" to true. >>> >>> Then i have *EXC_BAD_ACCESS (code=260, address=0xd10083ff)* in >>> ExecutionEngine.cpp file: >>> >>> return runFunction(Fn, GVArgs).IntVal.getZExtValue(); >>> >>> Tim? Anyone? I can provide source code and build scripts to reproduce >>> the case. >>> >>> Regards, Anton. >>> >>> 2014-09-17 19:02 GMT+06:00 Anton Smirnov <dev at antonsmirnov.name>: >>> >>>> Both Clang/LLVM 3.4 -> Clang/LLVM 3.5 >>>> And i will also try using MCJIT. >>>> >>>> 2014-09-17 18:56 GMT+06:00 Anton Smirnov <dev at antonsmirnov.name>: >>>> >>>>> Hi, Tim. >>>>> >>>>> I've used Clang 3.4 final release and now i'm going to test it with >>>>> 3.5 release (since i've read about arm64 improvements). >>>>> I will report my results. >>>>> >>>>> BTW, is it possible to get smth like "hello world" output even with >>>>> apple restrictions? >>>>> >>>>> Regards, Anton. >>>>> >>>>> 2014-09-17 18:42 GMT+06:00 Tim Northover <t.p.northover at gmail.com>: >>>>> >>>>>> Hi Anton, >>>>>> >>>>>> I've added the llvmdev list, since the issues you're seeing are coming >>>>>> from the backend, which is more their side. >>>>>> >>>>>> On 17 September 2014 08:43, Anton Smirnov <dev at antonsmirnov.name> >>>>>> wrote: >>>>>> > i've changed lli arguments to the next (instead of default): >>>>>> > >>>>>> > return llvm_interpret( >>>>>> > InputFile, >>>>>> > std::vector<std::string>(), >>>>>> > false, // ForceInterpreter >>>>>> > false, // UseMCJIT >>>>>> > [...] >>>>>> > Now i'm having: >>>>>> > >>>>>> > Unhandled instruction encoding format! >>>>>> > UNREACHABLE executed at >>>>>> > >>>>>> /Users/asmirnov/Documents/dev/src/llvm_34_ios/lib/Target/ARM/ARMCodeEmitter.cpp:547! >>>>>> >>>>>> This one at least is understandable. Your options imply (I couldn't >>>>>> find any "llvm_interpret" function, so there's some guesswork) that >>>>>> you're using the old JIT. That's been discouraged for a while, and >>>>>> it's been removed completely now in trunk. >>>>>> >>>>>> It's entirely possible it could randomly fall over (not all >>>>>> instructions are supported), and probably not even worth worrying >>>>>> about why. I'd just flip that "UseMCJIT" option. >>>>>> >>>>>> The interpreter failure you were seeing earlier is harder to explain >>>>>> (there are various options), but if we're lucky it won't happen in >>>>>> MCJIT mode. Then we don't have to worry about that one either. >>>>>> >>>>>> Cheers. >>>>>> >>>>>> Tim. >>>>>> >>>>> >>>>> >>>> >>> >> >> _______________________________________________ >> cfe-dev mailing list >> cfe-dev at cs.uiuc.edu >> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev >> >> >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140919/5b826475/attachment.html>
Hi Anton, I don't follow what you're asking? For (1): You can compile c++ files to .ll files with clang - it seems like you've already worked that out. For (2): What do you mean "supported at the moment"? In the 3.5 release MCJIT is known to be broken for MachO/ARM. The Interpreter and the JIT are both poorly tested (and seem to be broken, as you discovered). On the development branch many of the bugs in MCJIT have been fixed, and I would expect MCJIT to work for simple test cases. The JIT has been removed entirely, and the Interpreter is still poorly tested. :) I look forward to checking out the bug reports. Good luck! - Lang. On Thu, Sep 18, 2014 at 11:14 AM, Anton Smirnov <dev at antonsmirnov.name> wrote:> Hi, Lang. > > Thanks for clarification. I will check out current branch tomorrow and > report you back. > Most likely i will create bug issue with cleaned sources for static lib > and test ios app. > > Actually i'm not professional c++ dev so my question is - is there any > chance to do the next: > 1. compile .cpp code to .ll code (seems i already did it) > 2. interpret .ll file by any supported at the moment way (i'm not sure if > this can be done without relocations or smth like that)? > > I will do my best to assist you and i can test as soon as new commits are > coming. > > Regards, Anton. > > 2014-09-18 23:00 GMT+06:00 Lang Hames <lhames at gmail.com>: > >> Hi Anton, >> >> Could you file a bug with your source and build scripts at llvm.org/bugs >> and CC me on it? >> >> As Tim mentioned the old JIT was not well maintained in 3.4/3.5, and has >> been removed from LLVM's mainline. Unfortunately MCJIT's support for >> MachO/ARM didn't received much attention until recently either - MachO ARM >> relocations are totally broken in 3.5, so any symbolic references in the >> final object file (E.g. for @.str in your example) will lead to failures. >> >> I would recommend trying MCJIT with the current development branch of >> LLVM - you will probably have more luck there. >> >> Don't hesitate to file bugs for any issues you run in to on the >> development branch - the more test cases we have the easier it will be to >> get MachO/ARM fully supported in MCJIT. >> >> Regards, >> Lang. >> >> >> On Wed, Sep 17, 2014 at 12:11 PM, Anton Smirnov <dev at antonsmirnov.name> >> wrote: >> >>> I've also tried the next combination: >>> true, // ForceInterpreter >>> false, // UseMCJIT >>> and ios app just crashed with no output >>> >>> 2014-09-18 0:47 GMT+06:00 Anton Smirnov <dev at antonsmirnov.name>: >>> >>>> Hey. >>>> >>>> I've checked out LLVM/Clang 3.5 and modified my static libs source code >>>> to use the latest llvm/clang sources. >>>> Also i'm trying triple ""arm64-apple-ios7.0"" now as it's wriiten in >>>> 3.5 release notes. >>>> >>>> I'm having simple (and pretty useless) source file: >>>> int main(int count, const char **args) { >>>> const char *c = "hello world"; >>>> return 1 + 5; >>>> } >>>> >>>> i using the next llc params: >>>> const char *cmd[] = { >>>> "clang", >>>> "-cc1", >>>> "-triple", >>>> "arm64-apple-ios7.0", >>>> "-emit-llvm", >>>> "-disable-free", >>>> "-main-file-name", >>>> [cppShortFile UTF8String], // "hw.cpp" >>>> "-mrelocation-model", >>>> "pic", >>>> "-pic-level", >>>> "2", >>>> "-mdisable-fp-elim", >>>> "-masm-verbose", >>>> "-target-linker-version", >>>> "236.3", >>>> "-v", >>>> "-coverage-file", >>>> [llFile UTF8String], >>>> //"/private/var/mobile/Applications/175ECA7F-3175-4AC9-971C-85272F5492C4/tmp/hw.ll" >>>> "-resource-dir", >>>> [[[ASPathHolder sharedHolder] tempFolder] UTF8String], >>>> "-stdlib=libc++", >>>> "-fdeprecated-macro", >>>> "-fdebug-compilation-dir", >>>> [[[ASPathHolder sharedHolder] tempFolder] UTF8String], >>>> "-ferror-limit", >>>> "19", >>>> "-fmessage-length", >>>> "0", >>>> "-stack-protector", >>>> "1", >>>> "-mstackrealign", >>>> "-fcxx-exceptions", >>>> "-fexceptions", >>>> "-fdiagnostics-show-option", >>>> "-vectorize-slp", >>>> "-mfloat-abi", >>>> "soft", >>>> "-o", >>>> [llFile UTF8String], // >>>> /private/var/mobile/Applications/175ECA7F-3175-4AC9-971C-85272F5492C4/tmp/hw.ll >>>> "-x", >>>> "c++", >>>> [cppFile UTF8String] >>>> //"/private/var/mobile/Applications/175ECA7F-3175-4AC9-971C-85272F5492C4/tmp/hw.cpp" >>>> }; >>>> >>>> and i'm getting the next .ll code (which seems to be pretty close or >>>> exactly the same as previous one): >>>> ; ModuleID >>>> '/var/mobile/Applications/53D60D11-DF93-4129-AD97-B96424D165B5/Documents/projects/calc/calc.cpp' >>>> target datalayout = "e-m:o-i64:64-i128:128-n32:64-S128" >>>> target triple = "arm64-apple-ios7.0" >>>> >>>> @.str = private unnamed_addr constant [12 x i8] c"hello world\00", >>>> align 1 >>>> >>>> ; Function Attrs: nounwind ssp >>>> define i32 @main(i32 %count, i8** %args) #0 { >>>> entry: >>>> %retval = alloca i32, align 4 >>>> %count.addr = alloca i32, align 4 >>>> %args.addr = alloca i8**, align 8 >>>> %c = alloca i8*, align 8 >>>> store i32 0, i32* %retval >>>> store i32 %count, i32* %count.addr, align 4 >>>> store i8** %args, i8*** %args.addr, align 8 >>>> store i8* getelementptr inbounds ([12 x i8]* @.str, i32 0, i32 0), >>>> i8** %c, align 8 >>>> ret i32 6 >>>> } >>>> >>>> attributes #0 = { nounwind ssp "less-precise-fpmad"="false" >>>> "no-frame-pointer-elim"="true" "no-frame-pointer-elim-non-leaf" >>>> "no-infs-fp-math"="false" "no-nans-fp-math"="false" >>>> "stack-protector-buffer-size"="8" "unsafe-fp-math"="false" >>>> "use-soft-float"="false" } >>>> >>>> !llvm.ident = !{!0} >>>> >>>> !0 = metadata !{metadata !"clang version 3.5.0 (tags/RELEASE_350/final >>>> 217949)"} >>>> >>>> (Note changed triple and compiler version. Also note i'm not using >>>> "target-cpu" argument now as "cortex-a8" is not supported for this triple). >>>> >>>> Next i'm trying to interpret it (source code is copy-pasted from lli >>>> tool source code): >>>> >>>> // lli with my default arguments >>>> int llvm_interpret(const char *ll_filename) { >>>> std::string InputFile(ll_filename); >>>> >>>> return llvm_interpret( >>>> InputFile, >>>> std::vector<std::string>(), // argv >>>> false, // ForceInterpreter >>>> false, // UseMCJIT >>>> false, // DebugIR >>>> false, // RemoteMCJIT >>>> "", // ChildExecPath >>>> ' ', // OptLevel >>>> std::string("arm64-apple-ios7.0"), // TargetTriple >>>> std::string("arm64"), // MArch >>>> std::string(), // MCPU >>>> std::vector<std::string>(), // MAttrs >>>> "main", // EntryFunc >>>> std::vector<std::string>(), // ExtraModules >>>> std::vector<std::string>(), // ExtraObjects >>>> std::vector<std::string>(), // ExtraArchives >>>> false, // EnableCacheManager >>>> std::string(), // ObjectCacheDir >>>> std::string(), // FakeArgv0 >>>> false, // DisableCoreFiles >>>> false, // NoLazyCompilation >>>> Reloc::PIC_, // RelocModel >>>> CodeModel::JITDefault, // CMModel >>>> true, // GenerateSoftFloatCalls >>>> FloatABI::Soft, // FloatABIForCalls >>>> false, // EmitJitDebugInfo >>>> false // EmitJitDebugInfoToDisk >>>> ); >>>> >>>> I'm getting the next error text: >>>> *error creating EE: target does not support JIT code generation* >>>> >>>> Ok, let's try using MCJIT as i was suggested. >>>> Now change default value for "UseMCJIT" to true. >>>> >>>> Then i have *EXC_BAD_ACCESS (code=260, address=0xd10083ff)* in >>>> ExecutionEngine.cpp file: >>>> >>>> return runFunction(Fn, GVArgs).IntVal.getZExtValue(); >>>> >>>> Tim? Anyone? I can provide source code and build scripts to reproduce >>>> the case. >>>> >>>> Regards, Anton. >>>> >>>> 2014-09-17 19:02 GMT+06:00 Anton Smirnov <dev at antonsmirnov.name>: >>>> >>>>> Both Clang/LLVM 3.4 -> Clang/LLVM 3.5 >>>>> And i will also try using MCJIT. >>>>> >>>>> 2014-09-17 18:56 GMT+06:00 Anton Smirnov <dev at antonsmirnov.name>: >>>>> >>>>>> Hi, Tim. >>>>>> >>>>>> I've used Clang 3.4 final release and now i'm going to test it with >>>>>> 3.5 release (since i've read about arm64 improvements). >>>>>> I will report my results. >>>>>> >>>>>> BTW, is it possible to get smth like "hello world" output even with >>>>>> apple restrictions? >>>>>> >>>>>> Regards, Anton. >>>>>> >>>>>> 2014-09-17 18:42 GMT+06:00 Tim Northover <t.p.northover at gmail.com>: >>>>>> >>>>>>> Hi Anton, >>>>>>> >>>>>>> I've added the llvmdev list, since the issues you're seeing are >>>>>>> coming >>>>>>> from the backend, which is more their side. >>>>>>> >>>>>>> On 17 September 2014 08:43, Anton Smirnov <dev at antonsmirnov.name> >>>>>>> wrote: >>>>>>> > i've changed lli arguments to the next (instead of default): >>>>>>> > >>>>>>> > return llvm_interpret( >>>>>>> > InputFile, >>>>>>> > std::vector<std::string>(), >>>>>>> > false, // ForceInterpreter >>>>>>> > false, // UseMCJIT >>>>>>> > [...] >>>>>>> > Now i'm having: >>>>>>> > >>>>>>> > Unhandled instruction encoding format! >>>>>>> > UNREACHABLE executed at >>>>>>> > >>>>>>> /Users/asmirnov/Documents/dev/src/llvm_34_ios/lib/Target/ARM/ARMCodeEmitter.cpp:547! >>>>>>> >>>>>>> This one at least is understandable. Your options imply (I couldn't >>>>>>> find any "llvm_interpret" function, so there's some guesswork) that >>>>>>> you're using the old JIT. That's been discouraged for a while, and >>>>>>> it's been removed completely now in trunk. >>>>>>> >>>>>>> It's entirely possible it could randomly fall over (not all >>>>>>> instructions are supported), and probably not even worth worrying >>>>>>> about why. I'd just flip that "UseMCJIT" option. >>>>>>> >>>>>>> The interpreter failure you were seeing earlier is harder to explain >>>>>>> (there are various options), but if we're lucky it won't happen in >>>>>>> MCJIT mode. Then we don't have to worry about that one either. >>>>>>> >>>>>>> Cheers. >>>>>>> >>>>>>> Tim. >>>>>>> >>>>>> >>>>>> >>>>> >>>> >>> >>> _______________________________________________ >>> cfe-dev mailing list >>> cfe-dev at cs.uiuc.edu >>> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev >>> >>> >> >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140918/e7938507/attachment.html>
Hi, Lang. 2014-09-19 0:39 GMT+06:00 Lang Hames <lhames at gmail.com>:> Hi Anton, > > I don't follow what you're asking? > > For (1): You can compile c++ files to .ll files with clang - it seems like > you've already worked that out. > > For (2): What do you mean "supported at the moment"? In the 3.5 release > MCJIT is known to be broken for MachO/ARM. The Interpreter and the JIT are > both poorly tested (and seem to be broken, as you discovered). On the > development branch many of the bugs in MCJIT have been fixed, and I would > expect MCJIT to work for simple test cases. The JIT has been removed > entirely, and the Interpreter is still poorly tested. :) >You understood correctly what i was asking for.> > I look forward to checking out the bug reports. >Sure, just let me remove unneeded source code from my ios app and clean-up my build scripts for lli static lib.> > Good luck! > >Regards, Anton.> - Lang. > > > > On Thu, Sep 18, 2014 at 11:14 AM, Anton Smirnov <dev at antonsmirnov.name> > wrote: > >> Hi, Lang. >> >> Thanks for clarification. I will check out current branch tomorrow and >> report you back. >> Most likely i will create bug issue with cleaned sources for static lib >> and test ios app. >> >> Actually i'm not professional c++ dev so my question is - is there any >> chance to do the next: >> 1. compile .cpp code to .ll code (seems i already did it) >> 2. interpret .ll file by any supported at the moment way (i'm not sure if >> this can be done without relocations or smth like that)? >> >> I will do my best to assist you and i can test as soon as new commits are >> coming. >> >> Regards, Anton. >> >> 2014-09-18 23:00 GMT+06:00 Lang Hames <lhames at gmail.com>: >> >>> Hi Anton, >>> >>> Could you file a bug with your source and build scripts at llvm.org/bugs >>> and CC me on it? >>> >>> As Tim mentioned the old JIT was not well maintained in 3.4/3.5, and has >>> been removed from LLVM's mainline. Unfortunately MCJIT's support for >>> MachO/ARM didn't received much attention until recently either - MachO ARM >>> relocations are totally broken in 3.5, so any symbolic references in the >>> final object file (E.g. for @.str in your example) will lead to failures. >>> >>> I would recommend trying MCJIT with the current development branch of >>> LLVM - you will probably have more luck there. >>> >>> Don't hesitate to file bugs for any issues you run in to on the >>> development branch - the more test cases we have the easier it will be to >>> get MachO/ARM fully supported in MCJIT. >>> >>> Regards, >>> Lang. >>> >>> >>> On Wed, Sep 17, 2014 at 12:11 PM, Anton Smirnov <dev at antonsmirnov.name> >>> wrote: >>> >>>> I've also tried the next combination: >>>> true, // ForceInterpreter >>>> false, // UseMCJIT >>>> and ios app just crashed with no output >>>> >>>> 2014-09-18 0:47 GMT+06:00 Anton Smirnov <dev at antonsmirnov.name>: >>>> >>>>> Hey. >>>>> >>>>> I've checked out LLVM/Clang 3.5 and modified my static libs source >>>>> code to use the latest llvm/clang sources. >>>>> Also i'm trying triple ""arm64-apple-ios7.0"" now as it's wriiten in >>>>> 3.5 release notes. >>>>> >>>>> I'm having simple (and pretty useless) source file: >>>>> int main(int count, const char **args) { >>>>> const char *c = "hello world"; >>>>> return 1 + 5; >>>>> } >>>>> >>>>> i using the next llc params: >>>>> const char *cmd[] = { >>>>> "clang", >>>>> "-cc1", >>>>> "-triple", >>>>> "arm64-apple-ios7.0", >>>>> "-emit-llvm", >>>>> "-disable-free", >>>>> "-main-file-name", >>>>> [cppShortFile UTF8String], // "hw.cpp" >>>>> "-mrelocation-model", >>>>> "pic", >>>>> "-pic-level", >>>>> "2", >>>>> "-mdisable-fp-elim", >>>>> "-masm-verbose", >>>>> "-target-linker-version", >>>>> "236.3", >>>>> "-v", >>>>> "-coverage-file", >>>>> [llFile UTF8String], >>>>> //"/private/var/mobile/Applications/175ECA7F-3175-4AC9-971C-85272F5492C4/tmp/hw.ll" >>>>> "-resource-dir", >>>>> [[[ASPathHolder sharedHolder] tempFolder] UTF8String], >>>>> "-stdlib=libc++", >>>>> "-fdeprecated-macro", >>>>> "-fdebug-compilation-dir", >>>>> [[[ASPathHolder sharedHolder] tempFolder] UTF8String], >>>>> "-ferror-limit", >>>>> "19", >>>>> "-fmessage-length", >>>>> "0", >>>>> "-stack-protector", >>>>> "1", >>>>> "-mstackrealign", >>>>> "-fcxx-exceptions", >>>>> "-fexceptions", >>>>> "-fdiagnostics-show-option", >>>>> "-vectorize-slp", >>>>> "-mfloat-abi", >>>>> "soft", >>>>> "-o", >>>>> [llFile UTF8String], // >>>>> /private/var/mobile/Applications/175ECA7F-3175-4AC9-971C-85272F5492C4/tmp/hw.ll >>>>> "-x", >>>>> "c++", >>>>> [cppFile UTF8String] >>>>> //"/private/var/mobile/Applications/175ECA7F-3175-4AC9-971C-85272F5492C4/tmp/hw.cpp" >>>>> }; >>>>> >>>>> and i'm getting the next .ll code (which seems to be pretty close or >>>>> exactly the same as previous one): >>>>> ; ModuleID >>>>> '/var/mobile/Applications/53D60D11-DF93-4129-AD97-B96424D165B5/Documents/projects/calc/calc.cpp' >>>>> target datalayout = "e-m:o-i64:64-i128:128-n32:64-S128" >>>>> target triple = "arm64-apple-ios7.0" >>>>> >>>>> @.str = private unnamed_addr constant [12 x i8] c"hello world\00", >>>>> align 1 >>>>> >>>>> ; Function Attrs: nounwind ssp >>>>> define i32 @main(i32 %count, i8** %args) #0 { >>>>> entry: >>>>> %retval = alloca i32, align 4 >>>>> %count.addr = alloca i32, align 4 >>>>> %args.addr = alloca i8**, align 8 >>>>> %c = alloca i8*, align 8 >>>>> store i32 0, i32* %retval >>>>> store i32 %count, i32* %count.addr, align 4 >>>>> store i8** %args, i8*** %args.addr, align 8 >>>>> store i8* getelementptr inbounds ([12 x i8]* @.str, i32 0, i32 0), >>>>> i8** %c, align 8 >>>>> ret i32 6 >>>>> } >>>>> >>>>> attributes #0 = { nounwind ssp "less-precise-fpmad"="false" >>>>> "no-frame-pointer-elim"="true" "no-frame-pointer-elim-non-leaf" >>>>> "no-infs-fp-math"="false" "no-nans-fp-math"="false" >>>>> "stack-protector-buffer-size"="8" "unsafe-fp-math"="false" >>>>> "use-soft-float"="false" } >>>>> >>>>> !llvm.ident = !{!0} >>>>> >>>>> !0 = metadata !{metadata !"clang version 3.5.0 (tags/RELEASE_350/final >>>>> 217949)"} >>>>> >>>>> (Note changed triple and compiler version. Also note i'm not using >>>>> "target-cpu" argument now as "cortex-a8" is not supported for this triple). >>>>> >>>>> Next i'm trying to interpret it (source code is copy-pasted from lli >>>>> tool source code): >>>>> >>>>> // lli with my default arguments >>>>> int llvm_interpret(const char *ll_filename) { >>>>> std::string InputFile(ll_filename); >>>>> >>>>> return llvm_interpret( >>>>> InputFile, >>>>> std::vector<std::string>(), // argv >>>>> false, // ForceInterpreter >>>>> false, // UseMCJIT >>>>> false, // DebugIR >>>>> false, // RemoteMCJIT >>>>> "", // ChildExecPath >>>>> ' ', // OptLevel >>>>> std::string("arm64-apple-ios7.0"), // TargetTriple >>>>> std::string("arm64"), // MArch >>>>> std::string(), // MCPU >>>>> std::vector<std::string>(), // MAttrs >>>>> "main", // EntryFunc >>>>> std::vector<std::string>(), // ExtraModules >>>>> std::vector<std::string>(), // ExtraObjects >>>>> std::vector<std::string>(), // ExtraArchives >>>>> false, // EnableCacheManager >>>>> std::string(), // ObjectCacheDir >>>>> std::string(), // FakeArgv0 >>>>> false, // DisableCoreFiles >>>>> false, // NoLazyCompilation >>>>> Reloc::PIC_, // RelocModel >>>>> CodeModel::JITDefault, // CMModel >>>>> true, // GenerateSoftFloatCalls >>>>> FloatABI::Soft, // FloatABIForCalls >>>>> false, // EmitJitDebugInfo >>>>> false // EmitJitDebugInfoToDisk >>>>> ); >>>>> >>>>> I'm getting the next error text: >>>>> *error creating EE: target does not support JIT code generation* >>>>> >>>>> Ok, let's try using MCJIT as i was suggested. >>>>> Now change default value for "UseMCJIT" to true. >>>>> >>>>> Then i have *EXC_BAD_ACCESS (code=260, address=0xd10083ff)* in >>>>> ExecutionEngine.cpp file: >>>>> >>>>> return runFunction(Fn, GVArgs).IntVal.getZExtValue(); >>>>> >>>>> Tim? Anyone? I can provide source code and build scripts to reproduce >>>>> the case. >>>>> >>>>> Regards, Anton. >>>>> >>>>> 2014-09-17 19:02 GMT+06:00 Anton Smirnov <dev at antonsmirnov.name>: >>>>> >>>>>> Both Clang/LLVM 3.4 -> Clang/LLVM 3.5 >>>>>> And i will also try using MCJIT. >>>>>> >>>>>> 2014-09-17 18:56 GMT+06:00 Anton Smirnov <dev at antonsmirnov.name>: >>>>>> >>>>>>> Hi, Tim. >>>>>>> >>>>>>> I've used Clang 3.4 final release and now i'm going to test it with >>>>>>> 3.5 release (since i've read about arm64 improvements). >>>>>>> I will report my results. >>>>>>> >>>>>>> BTW, is it possible to get smth like "hello world" output even with >>>>>>> apple restrictions? >>>>>>> >>>>>>> Regards, Anton. >>>>>>> >>>>>>> 2014-09-17 18:42 GMT+06:00 Tim Northover <t.p.northover at gmail.com>: >>>>>>> >>>>>>>> Hi Anton, >>>>>>>> >>>>>>>> I've added the llvmdev list, since the issues you're seeing are >>>>>>>> coming >>>>>>>> from the backend, which is more their side. >>>>>>>> >>>>>>>> On 17 September 2014 08:43, Anton Smirnov <dev at antonsmirnov.name> >>>>>>>> wrote: >>>>>>>> > i've changed lli arguments to the next (instead of default): >>>>>>>> > >>>>>>>> > return llvm_interpret( >>>>>>>> > InputFile, >>>>>>>> > std::vector<std::string>(), >>>>>>>> > false, // ForceInterpreter >>>>>>>> > false, // UseMCJIT >>>>>>>> > [...] >>>>>>>> > Now i'm having: >>>>>>>> > >>>>>>>> > Unhandled instruction encoding format! >>>>>>>> > UNREACHABLE executed at >>>>>>>> > >>>>>>>> /Users/asmirnov/Documents/dev/src/llvm_34_ios/lib/Target/ARM/ARMCodeEmitter.cpp:547! >>>>>>>> >>>>>>>> This one at least is understandable. Your options imply (I couldn't >>>>>>>> find any "llvm_interpret" function, so there's some guesswork) that >>>>>>>> you're using the old JIT. That's been discouraged for a while, and >>>>>>>> it's been removed completely now in trunk. >>>>>>>> >>>>>>>> It's entirely possible it could randomly fall over (not all >>>>>>>> instructions are supported), and probably not even worth worrying >>>>>>>> about why. I'd just flip that "UseMCJIT" option. >>>>>>>> >>>>>>>> The interpreter failure you were seeing earlier is harder to explain >>>>>>>> (there are various options), but if we're lucky it won't happen in >>>>>>>> MCJIT mode. Then we don't have to worry about that one either. >>>>>>>> >>>>>>>> Cheers. >>>>>>>> >>>>>>>> Tim. >>>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>>> _______________________________________________ >>>> cfe-dev mailing list >>>> cfe-dev at cs.uiuc.edu >>>> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev >>>> >>>> >>> >> >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140919/b0767dc5/attachment.html>