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>
Hi, all.
I've cloned llvm/clang trunk sources, configured with the same arguments
(as for llvm 3.5 release):
--host=i386-apple-darwin11 --enable-threads=no --disable-threads
--disable-terminfo --enable-languages=c,c++ --enable-zlib=no --disable-zlib
--enable-targets=x86_64,arm,arm64
After that i recompiled my interpreter lib (remember it's almost lli) with
code changed (i was surprised how it's changed since 3.5 release!)
and created ios app that uses lib to test arm64 interpret issue. Then i was
surprised to get the next output:
*libInterpreter: error creating EE: No available targets are compatible
with this triple, see -version for the available targets.*
.ll file i'm trying to execute/interpret is almost as previous one (i've
added some code to it), but triple is the same:
; ModuleID = './test.cpp'
target datalayout = "e-m:o-i64:64-i128:128-n32:64-S128"
target triple = "arm64-apple-ios7.0.0"
@.str = private unnamed_addr constant [12 x i8] c"hello world\00",
align 1
; Function Attrs: nounwind ssp
define i32 @main(i32 %argc, i8** %argv) #0 {
entry:
%retval = alloca i32, align 4
%argc.addr = alloca i32, align 4
%argv.addr = alloca i8**, align 8
%c = alloca i8*, align 8
%a = alloca i32, align 4
%b = alloca i32, align 4
store i32 0, i32* %retval
store i32 %argc, i32* %argc.addr, align 4
store i8** %argv, i8*** %argv.addr, align 8
store i8* getelementptr inbounds ([12 x i8]* @.str, i32 0, i32 0), i8**
%c, align 8
store i32 1, i32* %a, align 4
%0 = load i32* %a, align 4
%add = add nsw i32 %0, 6
store i32 %add, i32* %b, align 4
ret i32 3
}
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.6.0 (trunk 218116) (llvm/trunk
218115)"}
I've compiled llvm_trunk (same source for host and compiled it using
-emit-llvm -S -c .. -o -target arm64-apple-ios7.0) so this target is
supported.
so i can't understand why i'm getting such error on the same code but on
arm (instead of my x86_64).
What should i do?
Regards, Anton.
2014-09-19 0:46 GMT+06:00 Anton Smirnov <dev at antonsmirnov.name>:
> 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/20140920/e95d5dd0/attachment.html>
i've found why it was unavailable to find target - changed InitializeNative* to InitializeAll* methods (see lli source code). Anyway now i'm just getting exception as i wrote before. I've posted bug report (http://llvm.org/bugs/show_bug.cgi?id=21012) with: 1. full issue description 2. static library sources 3. lib build script 4. ios app that uses lib and where you can reproduce exception i hope my efforts will be awarded and someone fix it. also i will do my best in order to fix it ASAP. please contact me on email or skype (anton.smirnov.skype) to get more information if needed. Cheers, Anton. 2014-09-20 15:23 GMT+06:00 Anton Smirnov <dev at antonsmirnov.name>:> Hi, all. > > I've cloned llvm/clang trunk sources, configured with the same arguments > (as for llvm 3.5 release): > > --host=i386-apple-darwin11 --enable-threads=no --disable-threads > --disable-terminfo --enable-languages=c,c++ --enable-zlib=no --disable-zlib > --enable-targets=x86_64,arm,arm64 > > After that i recompiled my interpreter lib (remember it's almost lli) with > code changed (i was surprised how it's changed since 3.5 release!) > > and created ios app that uses lib to test arm64 interpret issue. Then i > was surprised to get the next output: > > *libInterpreter: error creating EE: No available targets are compatible > with this triple, see -version for the available targets.* > > .ll file i'm trying to execute/interpret is almost as previous one (i've > added some code to it), but triple is the same: > > ; ModuleID = './test.cpp' > > target datalayout = "e-m:o-i64:64-i128:128-n32:64-S128" > > target triple = "arm64-apple-ios7.0.0" > > > @.str = private unnamed_addr constant [12 x i8] c"hello world\00", align 1 > > > ; Function Attrs: nounwind ssp > > define i32 @main(i32 %argc, i8** %argv) #0 { > > entry: > > %retval = alloca i32, align 4 > > %argc.addr = alloca i32, align 4 > > %argv.addr = alloca i8**, align 8 > > %c = alloca i8*, align 8 > > %a = alloca i32, align 4 > > %b = alloca i32, align 4 > > store i32 0, i32* %retval > > store i32 %argc, i32* %argc.addr, align 4 > > store i8** %argv, i8*** %argv.addr, align 8 > > store i8* getelementptr inbounds ([12 x i8]* @.str, i32 0, i32 0), i8** > %c, align 8 > > store i32 1, i32* %a, align 4 > > %0 = load i32* %a, align 4 > > %add = add nsw i32 %0, 6 > > store i32 %add, i32* %b, align 4 > > ret i32 3 > > } > > > 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.6.0 (trunk 218116) (llvm/trunk > 218115)"} > I've compiled llvm_trunk (same source for host and compiled it using > -emit-llvm -S -c .. -o -target arm64-apple-ios7.0) so this target is > supported. > so i can't understand why i'm getting such error on the same code but on > arm (instead of my x86_64). > > What should i do? > > Regards, Anton. > > 2014-09-19 0:46 GMT+06:00 Anton Smirnov <dev at antonsmirnov.name>: > >> 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/20140920/8fd91ae2/attachment.html>