Displaying 12 results from an estimated 12 matches for "sunkaddr29".
Did you mean:
sunkaddr27
2013 Nov 12
2
[LLVMdev] sinking address computing in CodeGenPrepare
...= getelementptr inbounds %struct.SS* %a2, i32 0, i32 35
for.body:
%4 = load double* %zzz, align 8, !tbaa !0
TO :
for.body:
%sunkaddr27 = ptrtoint %struct.SS* %a2 to i32 <----- sink address computing into user's block
%sunkaddr28 = add i32 %sunkaddr27, 272
%sunkaddr29 = inttoptr i32 %sunkaddr28 to double*
%4 = load double* %sunkaddr29, align 8, !tbaa !8
>From what I observed, this transformation can cause poor alias analysis results without using GEP. So, I want to see there is any way to avoid this conversion.
My question is :
1. Why do we need to sin...
2013 Nov 12
2
[LLVMdev] sinking address computing in CodeGenPrepare
...gt;> for.body:
>> %4 = load double* %zzz, align 8, !tbaa !0
>>
>> TO :
>> for.body:
>> %sunkaddr27 = ptrtoint %struct.SS* %a2 to i32 <----- sink address computing into user's block
>> %sunkaddr28 = add i32 %sunkaddr27, 272
>> %sunkaddr29 = inttoptr i32 %sunkaddr28 to double*
>> %4 = load double* %sunkaddr29, align 8, !tbaa !8
>>
>>
>> From what I observed, this transformation can cause poor alias analysis results without using GEP. So, I want to see there is any way to avoid this conversion.
>>
>...
2013 Nov 12
0
[LLVMdev] sinking address computing in CodeGenPrepare
...2, i32 0, i32 35
>
> for.body:
> %4 = load double* %zzz, align 8, !tbaa !0
>
> TO :
> for.body:
> %sunkaddr27 = ptrtoint %struct.SS* %a2 to i32 <----- sink address computing into user's block
> %sunkaddr28 = add i32 %sunkaddr27, 272
> %sunkaddr29 = inttoptr i32 %sunkaddr28 to double*
> %4 = load double* %sunkaddr29, align 8, !tbaa !8
>
>
> From what I observed, this transformation can cause poor alias analysis results without using GEP. So, I want to see there is any way to avoid this conversion.
>
> My question is :...
2013 Nov 20
2
[LLVMdev] sinking address computing in CodeGenPrepare
...ad double* %zzz, align 8, !tbaa !0
>>>>
>>>> TO :
>>>> for.body:
>>>> %sunkaddr27 = ptrtoint %struct.SS* %a2 to i32 <----- sink address computing into user's block
>>>> %sunkaddr28 = add i32 %sunkaddr27, 272
>>>> %sunkaddr29 = inttoptr i32 %sunkaddr28 to double*
>>>> %4 = load double* %sunkaddr29, align 8, !tbaa !8
>>>>
>>>>
>>>> From what I observed, this transformation can cause poor alias analysis results without using GEP. So, I want to see there is any way to avoi...
2013 Nov 13
0
[LLVMdev] sinking address computing in CodeGenPrepare
...gt; %4 = load double* %zzz, align 8, !tbaa !0
>>>
>>> TO :
>>> for.body:
>>> %sunkaddr27 = ptrtoint %struct.SS* %a2 to i32 <----- sink address computing into user's block
>>> %sunkaddr28 = add i32 %sunkaddr27, 272
>>> %sunkaddr29 = inttoptr i32 %sunkaddr28 to double*
>>> %4 = load double* %sunkaddr29, align 8, !tbaa !8
>>>
>>>
>>> From what I observed, this transformation can cause poor alias analysis results without using GEP. So, I want to see there is any way to avoid this conversio...
2013 Nov 21
2
[LLVMdev] sinking address computing in CodeGenPrepare
...gt;> TO :
> >>>>> for.body:
> >>>>> %sunkaddr27 = ptrtoint %struct.SS* %a2 to i32 <----- sink
> >>>>> address computing into user's block
> >>>>> %sunkaddr28 = add i32 %sunkaddr27, 272
> >>>>> %sunkaddr29 = inttoptr i32 %sunkaddr28 to double*
> >>>>> %4 = load double* %sunkaddr29, align 8, !tbaa !8
> >>>>>
> >>>>>
> >>>>> From what I observed, this transformation can cause poor alias
> >>>>> analysis results...
2013 Nov 21
0
[LLVMdev] sinking address computing in CodeGenPrepare
..., !tbaa !0
>>>>>
>>>>> TO :
>>>>> for.body:
>>>>> %sunkaddr27 = ptrtoint %struct.SS* %a2 to i32 <----- sink address computing into user's block
>>>>> %sunkaddr28 = add i32 %sunkaddr27, 272
>>>>> %sunkaddr29 = inttoptr i32 %sunkaddr28 to double*
>>>>> %4 = load double* %sunkaddr29, align 8, !tbaa !8
>>>>>
>>>>>
>>>>> From what I observed, this transformation can cause poor alias analysis results without using GEP. So, I want to see there is...
2013 Nov 21
3
[LLVMdev] sinking address computing in CodeGenPrepare
...>>>> %sunkaddr27 = ptrtoint %struct.SS* %a2 to i32 <-----
> >>>>>>> sink
> >>>>>>> address computing into user's block
> >>>>>>> %sunkaddr28 = add i32 %sunkaddr27, 272
> >>>>>>> %sunkaddr29 = inttoptr i32 %sunkaddr28 to double*
> >>>>>>> %4 = load double* %sunkaddr29, align 8, !tbaa !8
> >>>>>>>
> >>>>>>>
> >>>>>>> From what I observed, this transformation can cause poor
> >>>...
2013 Nov 21
0
[LLVMdev] sinking address computing in CodeGenPrepare
...t;>>>>>> for.body:
>>>>>>> %sunkaddr27 = ptrtoint %struct.SS* %a2 to i32 <----- sink
>>>>>>> address computing into user's block
>>>>>>> %sunkaddr28 = add i32 %sunkaddr27, 272
>>>>>>> %sunkaddr29 = inttoptr i32 %sunkaddr28 to double*
>>>>>>> %4 = load double* %sunkaddr29, align 8, !tbaa !8
>>>>>>>
>>>>>>>
>>>>>>> From what I observed, this transformation can cause poor alias
>>>>>>> an...
2013 Nov 22
0
[LLVMdev] sinking address computing in CodeGenPrepare
...> %sunkaddr27 = ptrtoint %struct.SS* %a2 to i32 <-----
>>>>>>>>> sink
>>>>>>>>> address computing into user's block
>>>>>>>>> %sunkaddr28 = add i32 %sunkaddr27, 272
>>>>>>>>> %sunkaddr29 = inttoptr i32 %sunkaddr28 to double*
>>>>>>>>> %4 = load double* %sunkaddr29, align 8, !tbaa !8
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> From what I observed, this transformation can cause poor
>&...
2013 Nov 22
2
[LLVMdev] sinking address computing in CodeGenPrepare
...= ptrtoint %struct.SS* %a2 to i32 <-----
>>>>>>>>>> sink
>>>>>>>>>> address computing into user's block
>>>>>>>>>> %sunkaddr28 = add i32 %sunkaddr27, 272
>>>>>>>>>> %sunkaddr29 = inttoptr i32 %sunkaddr28 to double*
>>>>>>>>>> %4 = load double* %sunkaddr29, align 8, !tbaa !8
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> From what I observed, this transformation can...
2013 Nov 26
0
[LLVMdev] sinking address computing in CodeGenPrepare
...uct.SS* %a2 to i32 <-----
>>>>>>>>>>> sink
>>>>>>>>>>> address computing into user's block
>>>>>>>>>>> %sunkaddr28 = add i32 %sunkaddr27, 272
>>>>>>>>>>> %sunkaddr29 = inttoptr i32 %sunkaddr28 to double*
>>>>>>>>>>> %4 = load double* %sunkaddr29, align 8, !tbaa !8
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> From what I observed, this tra...