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. >>>> >>> >>> >> >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140918/81616956/attachment.html>
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/363ac69b/attachment.html>
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>