Displaying 6 results from an estimated 6 matches for "julia_type".
2012 Jun 21
2
[LLVMdev] problem using 128-bit integer on x86-32
...%jl_value_t** %1, align 4, !dbg !5139
%4 = getelementptr inbounds %jl_value_t* %3, i32 0, i32 0, !dbg !5139
%5 = getelementptr %jl_value_t** %4, i32 1, !dbg !5139
%6 = bitcast %jl_value_t** %5 to i128*, !dbg !5139
%7 = load i128* %6, align 4, !dbg !5139
%8 = mul i128 %7, 137, !dbg !5146, !julia_type !5147
%9 = call %jl_value_t* @allocobj(i32 20), !dbg !5146
%10 = getelementptr inbounds %jl_value_t* %9, i32 0, i32 0, !dbg !5146
store %jl_value_t* inttoptr (i32 159792480 to %jl_value_t*),
%jl_value_t** %10, align 4, !dbg !5146
%11 = getelementptr %jl_value_t** %10, i32 1, !dbg !5146
%1...
2012 Jun 22
0
[LLVMdev] problem using 128-bit integer on x86-32
...g !5139
> %4 = getelementptr inbounds %jl_value_t* %3, i32 0, i32 0, !dbg !5139
> %5 = getelementptr %jl_value_t** %4, i32 1, !dbg !5139
> %6 = bitcast %jl_value_t** %5 to i128*, !dbg !5139
> %7 = load i128* %6, align 4, !dbg !5139
> %8 = mul i128 %7, 137, !dbg !5146, !julia_type !5147
> %9 = call %jl_value_t* @allocobj(i32 20), !dbg !5146
> %10 = getelementptr inbounds %jl_value_t* %9, i32 0, i32 0, !dbg !5146
> store %jl_value_t* inttoptr (i32 159792480 to %jl_value_t*),
> %jl_value_t** %10, align 4, !dbg !5146
> %11 = getelementptr %jl_value_t*...
2014 Feb 03
2
[LLVMdev] Weird msan problem
...e i32 0, i32* inttoptr (i64 add (i64 ptrtoint ([1000 x i32]*
> @__msan_param_origin_tls to i64), i64 16) to i32*), align 4, !dbg !7
> store i32 0, i32* bitcast ([8 x i64]* @__msan_retval_tls to i32*), align
> 8, !dbg !7
> %118 = call i32 %117(i32* %116, i64 %87, i64 %107), !dbg !7, !julia_type
> !9
>
>
>
> On Sun, Feb 2, 2014 at 6:18 AM, Evgeniy Stepanov <eugeni.stepanov at gmail.com>
> wrote:
>>
>> How is ccall() implemented? If it manually sets up a stack frame, then
>> it also needs to store argument shadow values in paramtls.
>>
>>...
2014 Feb 05
2
[LLVMdev] Weird msan problem
...i32]*
>> > @__msan_param_origin_tls to i64), i64 16) to i32*), align 4, !dbg !7
>> > store i32 0, i32* bitcast ([8 x i64]* @__msan_retval_tls to i32*),
>> align
>> > 8, !dbg !7
>> > %118 = call i32 %117(i32* %116, i64 %87, i64 %107), !dbg !7,
>> !julia_type
>> > !9
>> >
>> >
>> >
>> > On Sun, Feb 2, 2014 at 6:18 AM, Evgeniy Stepanov <
>> eugeni.stepanov at gmail.com>
>> > wrote:
>> >>
>> >> How is ccall() implemented? If it manually sets up a stack frame, then
&g...
2014 Feb 07
2
[LLVMdev] Weird msan problem
...i64 16) to i32*), align 4, !dbg !7
> >>> > store i32 0, i32* bitcast ([8 x i64]* @__msan_retval_tls to i32*),
> >>> > align
> >>> > 8, !dbg !7
> >>> > %118 = call i32 %117(i32* %116, i64 %87, i64 %107), !dbg !7,
> >>> > !julia_type
> >>> > !9
> >>> >
> >>> >
> >>> >
> >>> > On Sun, Feb 2, 2014 at 6:18 AM, Evgeniy Stepanov
> >>> > <eugeni.stepanov at gmail.com>
> >>> > wrote:
> >>> >>
> >>&g...
2014 Feb 02
2
[LLVMdev] Weird msan problem
How is ccall() implemented? If it manually sets up a stack frame, then
it also needs to store argument shadow values in paramtls.
I don't think there is an overflow, unless you have a _lot_ of
arguments in a function call.
On Sun, Feb 2, 2014 at 9:26 AM, Keno Fischer
<kfischer at college.harvard.edu> wrote:
> Also, I was looking at the instrumented LLVM code and I noticed that the