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

If this information is useful, please help other people find it:
Share via:

Junbum Lim

2013-Nov-20 23:10 UTC

[LLVMdev] sinking address computing in CodeGenPrepare

When multiple GEPs or other operations are used for the address calculation,
OptimizeMemoryInst() performs address matching and determines a final addressing
expression as a simple form (e.g., ptrtoint/add/inttoptr) and sinks it into
user's block so that ISel could have better chance to fold address
computation into LDRs and STRs. However, OptimizeMemoryInst() seems to do this
transformation even when the address calculation derived from a single GEP,
resulting in poor alias analysis because GEP is no longer used.

So, do you think it is a possible workaround to sink a GEP without converting it
into a set of integer operations (ptrtoint/add/inttoptr) if the address mode is
derived only from a single GEP.
 
Thanks,
Jun


On Nov 12, 2013, at 7:14 PM, Evan Cheng <evan.cheng at apple.com> wrote:
> 
> On Nov 12, 2013, at 11:24 AM, Junbum Lim <junbums at gmail.com>
wrote:
> 
>> 
>> 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.
> 
> I believe it's primary for address mode matching where only part of the
GEP can be folded (depending on the instruction set).
> 
> Evan
> 
>> 
>> 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
>> 
>

Evan Cheng

2013-Nov-21 01:01 UTC

head link

[LLVMdev] sinking address computing in CodeGenPrepare

On Nov 20, 2013, at 3:10 PM, Junbum Lim <junbums at gmail.com> wrote:
> 
> 
> When multiple GEPs or other operations are used for the address
calculation, OptimizeMemoryInst() performs address matching and determines a
final addressing expression as a simple form (e.g., ptrtoint/add/inttoptr) and
sinks it into user's block so that ISel could have better chance to fold
address computation into LDRs and STRs. However, OptimizeMemoryInst() seems to
do this transformation even when the address calculation derived from a single
GEP, resulting in poor alias analysis because GEP is no longer used.
I don't follow your last statement. How does this impact AA? CodeGenPrep is
run late, after AA is done.

Evan
> 
> So, do you think it is a possible workaround to sink a GEP without
converting it into a set of integer operations (ptrtoint/add/inttoptr) if the
address mode is derived only from a single GEP.
> 
> Thanks,
> Jun
> 
> 
> On Nov 12, 2013, at 7:14 PM, Evan Cheng <evan.cheng at apple.com>
wrote:
> 
>> 
>> On Nov 12, 2013, at 11:24 AM, Junbum Lim <junbums at gmail.com>
wrote:
>> 
>>> 
>>> 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.
>> 
>> I believe it's primary for address mode matching where only part of
the GEP can be folded (depending on the instruction set).
>> 
>> Evan
>> 
>>> 
>>> 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
>>> 
>> 
>

Hal Finkel

2013-Nov-21 01:38 UTC

head link

[LLVMdev] sinking address computing in CodeGenPrepare

----- Original Message -----> From: "Evan Cheng" <evan.cheng at apple.com>
> To: "Junbum Lim" <junbums at gmail.com>
> Cc: llvmdev at cs.uiuc.edu
> Sent: Wednesday, November 20, 2013 7:01:49 PM
> Subject: Re: [LLVMdev] sinking  address computing in CodeGenPrepare
> 
> 
> On Nov 20, 2013, at 3:10 PM, Junbum Lim <junbums at gmail.com> wrote:
> 
> > 
> > 
> > When multiple GEPs or other operations are used for the address
> > calculation, OptimizeMemoryInst() performs address matching and
> > determines a final addressing expression as a simple form (e.g.,
> > ptrtoint/add/inttoptr) and sinks it into user's block so that ISel
> > could have better chance to fold address computation into LDRs and
> > STRs. However, OptimizeMemoryInst() seems to do this
> > transformation even when the address calculation derived from a
> > single GEP, resulting in poor alias analysis because GEP is no
> > longer used.
> 
> I don't follow your last statement. How does this impact AA?
> CodeGenPrep is run late, after AA is done.
I don't know if this is relevant for Lim or not, but some targets use AA
during CodeGen (instruction scheduling mostly, but SDAG too).

 -Hal
> 
> Evan
> 
> > 
> > So, do you think it is a possible workaround to sink a GEP without
> > converting it into a set of integer operations
> > (ptrtoint/add/inttoptr) if the address mode is derived only from a
> > single GEP.
> > 
> > Thanks,
> > Jun
> > 
> > 
> > On Nov 12, 2013, at 7:14 PM, Evan Cheng <evan.cheng at
apple.com>
> > wrote:
> > 
> >> 
> >> On Nov 12, 2013, at 11:24 AM, Junbum Lim <junbums at
gmail.com>
> >> wrote:
> >> 
> >>> 
> >>> 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.
> >> 
> >> I believe it's primary for address mode matching where only
part
> >> of the GEP can be folded (depending on the instruction set).
> >> 
> >> Evan
> >> 
> >>> 
> >>> 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
> >>> 
> >> 
> > 
> 
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
> 
-- 
Hal Finkel
Assistant Computational Scientist
Leadership Computing Facility
Argonne National Laboratory

Possibly Parallel Threads

Search for more reasonably related threads

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

[LLVMdev] sinking address computing in CodeGenPrepare

[LLVMdev] sinking address computing in CodeGenPrepare

[LLVMdev] sinking address computing in CodeGenPrepare

Possibly Parallel Threads