search for: inttopt

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....

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 lo...

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,...

...s 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...

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 lo...

...; > >>> > >>> 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 ca...

...te: >> >>> >>> >>> 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, r...

...>> >>>>> 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...

...t;>>>> 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 >>>>>> tran...

...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. W...

...tr 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...

...t;> 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 >>>&...