llvm dev - Nov 2013 - [LLVMdev] sinking address computing in CodeGenPrepare

Hi All,

In CodeGenPrepare pass,  OptimizeMemoryInst() try to sink  address computing
into users' block by converting GET to integers? It appear that it have
impacts on ISel's result, but I'm not clear about the main purpose of
the transformation.

FROM :
for.body.lr.ph:
                %zzz = 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 sink address computing into users' block? What is the
benefit of this conversion ?
2. Can we directly use GEP instead of breaking it into integer calculations ? 
 
Thanks,
Jun

The reason for this is to allow folding of address computation into loads and
stores. A lot of modern arch, e.g. X86 and arm, have complex addressing mode.

Evan

Sent from my iPad
> On Nov 12, 2013, at 8:39 AM, Junbum Lim <junbums at gmail.com> wrote:
> 
> Hi All,
> 
> In CodeGenPrepare pass,  OptimizeMemoryInst() try to sink  address
computing into users' block by converting GET to integers? It appear that it
have impacts on ISel's result, but I'm not clear about the main purpose
of the transformation.
> 
> FROM :
> for.body.lr.ph:
>                %zzz = 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 sink address computing into users' block? What is
the benefit of this conversion ?
> 2. Can we directly use GEP instead of breaking it into integer calculations
?
> 
> Thanks,
> Jun
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

I wonder why CodeGenPrepare breaks GEP into integer calculations
(ptrtoin/add/inttopt) instead of directly sinking the address calculation using
GEP into user's block.

Thanks,
Jun


On Nov 12, 2013, at 12:07 PM, Evan Cheng <evan.cheng at apple.com> wrote:
> The reason for this is to allow folding of address computation into loads
and stores. A lot of modern arch, e.g. X86 and arm, have complex addressing
mode.
> 
> Evan
> 
> Sent from my iPad
> 
>> On Nov 12, 2013, at 8:39 AM, Junbum Lim <junbums at gmail.com>
wrote:
>> 
>> Hi All,
>> 
>> In CodeGenPrepare pass,  OptimizeMemoryInst() try to sink  address
computing into users' block by converting GET to integers? It appear that it
have impacts on ISel's result, but I'm not clear about the main purpose
of the transformation.
>> 
>> FROM :
>> for.body.lr.ph:
>>               %zzz = 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 sink address computing into users' block? What
is the benefit of this conversion ?
>> 2. Can we directly use GEP instead of breaking it into integer
calculations ?
>> 
>> Thanks,
>> Jun
>> _______________________________________________
>> LLVM Developers mailing list
>> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev