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/20140917/2e3c456f/attachment.html>
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/5002f02f/attachment.html>
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>