Terry Guo via llvm-dev
2020-Jul-23 15:48 UTC
[llvm-dev] How to optimize out the duplicated memory load instructions?
Hi Johannes,
Thanks for your help. I tried with something like below and nothing
changes. Maybe I am doing something wrong?
246001 check_exce_succ59: ; preds
%check_exce_succ40
**246002 %mem_base60 = load i8*, i8** %mem_base_addr_ptr, align 8,
!alias.scope !3
246003 %offset161 = add i32 %call56, 4
246004 %12 = sext i32 %offset161 to i64
246005 %maddr62 = getelementptr inbounds i8, i8* %mem_base60, i64 %12
246006 %data_ptr63 = bitcast i8* %maddr62 to i64*
**246007 store i64 0, i64* %data_ptr63, align 1, !noalias !3
**246008 %mem_base66 = load i8*, i8** %mem_base_addr_ptr, align 8,
!alias.scope !3
246009 %offset167 = add i32 %call56, 12
246010 %13 = sext i32 %offset167 to i64
....
382681 !3 = !{!3}
382682 !4 = !{!4}
BR,
Terry
On Thu, Jul 23, 2020 at 11:43 PM Johannes Doerfert <
johannesdoerfert at gmail.com> wrote:
> Hi Terry,
>
>
> various LLVM passes that run with O3 would do this for you, assuming
> they could prove correctness.
>
> FWIW, the address is the same, so it is (most likely) an aliasing
> problem. I assume
>
> store i64 0, i64* %data_ptr63, align 8
>
> might clobber the loaded location so we do not reuse the first load. You
> use alias metadata in IR or
>
> `noalias` (in IR) [= `restrict` (in C/C++)] attributes for arguments to
> help the alias analysis.
>
>
> Is this what you were looking for?
>
>
> ~ Johannes
>
>
> On 7/23/20 10:25 AM, Terry Guo via llvm-dev wrote:
> > Hi there,
> >
> > The raw input IR is composed by my tool and the below one is produced
by
> > llvm opt tool with O3 optimization level. I am pretty sure that the
two
> > load instructions( %mem_base60 and %mem_base66) are referring to the
> same
> > memory location. How can I instruct llvm optimization pass to optimize
> out
> > the %mem_base66 and make the subsequent code reuse the %mem_base60?
I
> > tried with metadata 'alias.scope' and 'noalias' and it
doesn't help.
> Thanks
> > for any advice.
> >
> > 392542 check_exce_succ59: ; preds >
> %check_exce_succ40
> > **392543 %mem_base60 = load i8*, i8** %mem_base_addr_ptr, align 8
> > 392544 %offset161 = add i32 %call56, 4
> > 392545 %11 = sext i32 %offset161 to i64
> > 392546 %maddr62 = getelementptr inbounds i8, i8* %mem_base60, i64
%11
> > 392547 %data_ptr63 = bitcast i8* %maddr62 to i64*
> > 392548 store i64 0, i64* %data_ptr63, align 8
> > **392549 %mem_base66 = load i8*, i8** %mem_base_addr_ptr, align 8
> > 392550 %offset167 = add i32 %call56, 12
> > 392551 %12 = sext i32 %offset167 to i64
> > 392552 %maddr68 = getelementptr inbounds i8, i8* %mem_base66, i64
%12
> > 392553 %data_ptr69 = bitcast i8* %maddr68 to i32*
> > 392554 store i32 %call, i32* %data_ptr69, align 8
> >
> > BR,
> > Terry
> >
> >
> > _______________________________________________
> > LLVM Developers mailing list
> > llvm-dev at lists.llvm.org
> > https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20200723/df59fd46/attachment.html>
Johannes Doerfert via llvm-dev
2020-Jul-23 16:10 UTC
[llvm-dev] How to optimize out the duplicated memory load instructions?
`noalias` metadata is more complex than this: https://llvm.org/docs/LangRef.html#noalias-and-alias-scope-metadata I doubt the below was accepted by the AliasAnalysis as valid annotations and consequently ignored. On 7/23/20 10:48 AM, Terry Guo wrote:> Hi Johannes, > > Thanks for your help. I tried with something like below and nothing > changes. Maybe I am doing something wrong? > > 246001 check_exce_succ59: ; preds > %check_exce_succ40 > **246002 %mem_base60 = load i8*, i8** %mem_base_addr_ptr, align 8, > !alias.scope !3 > 246003 %offset161 = add i32 %call56, 4 > 246004 %12 = sext i32 %offset161 to i64 > 246005 %maddr62 = getelementptr inbounds i8, i8* %mem_base60, i64 %12 > 246006 %data_ptr63 = bitcast i8* %maddr62 to i64* > **246007 store i64 0, i64* %data_ptr63, align 1, !noalias !3 > **246008 %mem_base66 = load i8*, i8** %mem_base_addr_ptr, align 8, > !alias.scope !3 > 246009 %offset167 = add i32 %call56, 12 > 246010 %13 = sext i32 %offset167 to i64 > .... > 382681 !3 = !{!3} > 382682 !4 = !{!4} > > BR, > Terry > > On Thu, Jul 23, 2020 at 11:43 PM Johannes Doerfert < > johannesdoerfert at gmail.com> wrote: > >> Hi Terry, >> >> >> various LLVM passes that run with O3 would do this for you, assuming >> they could prove correctness. >> >> FWIW, the address is the same, so it is (most likely) an aliasing >> problem. I assume >> >> store i64 0, i64* %data_ptr63, align 8 >> >> might clobber the loaded location so we do not reuse the first load. You >> use alias metadata in IR or >> >> `noalias` (in IR) [= `restrict` (in C/C++)] attributes for arguments to >> help the alias analysis. >> >> >> Is this what you were looking for? >> >> >> ~ Johannes >> >> >> On 7/23/20 10:25 AM, Terry Guo via llvm-dev wrote: >>> Hi there, >>> >>> The raw input IR is composed by my tool and the below one is produced by >>> llvm opt tool with O3 optimization level. I am pretty sure that the two >>> load instructions( %mem_base60 and %mem_base66) are referring to the >> same >>> memory location. How can I instruct llvm optimization pass to optimize >> out >>> the %mem_base66 and make the subsequent code reuse the %mem_base60? I >>> tried with metadata 'alias.scope' and 'noalias' and it doesn't help. >> Thanks >>> for any advice. >>> >>> 392542 check_exce_succ59: ; preds >>> %check_exce_succ40 >>> **392543 %mem_base60 = load i8*, i8** %mem_base_addr_ptr, align 8 >>> 392544 %offset161 = add i32 %call56, 4 >>> 392545 %11 = sext i32 %offset161 to i64 >>> 392546 %maddr62 = getelementptr inbounds i8, i8* %mem_base60, i64 %11 >>> 392547 %data_ptr63 = bitcast i8* %maddr62 to i64* >>> 392548 store i64 0, i64* %data_ptr63, align 8 >>> **392549 %mem_base66 = load i8*, i8** %mem_base_addr_ptr, align 8 >>> 392550 %offset167 = add i32 %call56, 12 >>> 392551 %12 = sext i32 %offset167 to i64 >>> 392552 %maddr68 = getelementptr inbounds i8, i8* %mem_base66, i64 %12 >>> 392553 %data_ptr69 = bitcast i8* %maddr68 to i32* >>> 392554 store i32 %call, i32* %data_ptr69, align 8 >>> >>> BR, >>> Terry >>> >>> >>> _______________________________________________ >>> LLVM Developers mailing list >>> llvm-dev at lists.llvm.org >>> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
Terry Guo via llvm-dev
2020-Jul-23 16:15 UTC
[llvm-dev] How to optimize out the duplicated memory load instructions?
Hi Johannes,
Silly as me. I just figured out how to correctly use 'alias' metadata. I
should define them in IR like below:
!3 = !{!3}
!4 = !{!4}
!5 = !{!5, !3}
!6 = !{!6, !4}
And then use !5 and !6. The below usage is wrong:
!3 = !{!3}
!4 = !{!4}
Then use !3 and !4 in IR.
BR,
Terry
On Fri, Jul 24, 2020 at 12:12 AM Johannes Doerfert <
johannesdoerfert at gmail.com> wrote:
> `noalias` metadata is more complex than this:
>
> https://llvm.org/docs/LangRef.html#noalias-and-alias-scope-metadata
>
> I doubt the below was accepted by the AliasAnalysis as valid annotations
> and consequently ignored.
>
>
> On 7/23/20 10:48 AM, Terry Guo wrote:
> > Hi Johannes,
> >
> > Thanks for your help. I tried with something like below and nothing
> > changes. Maybe I am doing something wrong?
> >
> > 246001 check_exce_succ59: ; preds >
> %check_exce_succ40
> > **246002 %mem_base60 = load i8*, i8** %mem_base_addr_ptr, align 8,
> > !alias.scope !3
> > 246003 %offset161 = add i32 %call56, 4
> > 246004 %12 = sext i32 %offset161 to i64
> > 246005 %maddr62 = getelementptr inbounds i8, i8* %mem_base60, i64
%12
> > 246006 %data_ptr63 = bitcast i8* %maddr62 to i64*
> > **246007 store i64 0, i64* %data_ptr63, align 1, !noalias !3
> > **246008 %mem_base66 = load i8*, i8** %mem_base_addr_ptr, align 8,
> > !alias.scope !3
> > 246009 %offset167 = add i32 %call56, 12
> > 246010 %13 = sext i32 %offset167 to i64
> > ....
> > 382681 !3 = !{!3}
> > 382682 !4 = !{!4}
> >
> > BR,
> > Terry
> >
> > On Thu, Jul 23, 2020 at 11:43 PM Johannes Doerfert <
> > johannesdoerfert at gmail.com> wrote:
> >
> >> Hi Terry,
> >>
> >>
> >> various LLVM passes that run with O3 would do this for you,
assuming
> >> they could prove correctness.
> >>
> >> FWIW, the address is the same, so it is (most likely) an aliasing
> >> problem. I assume
> >>
> >> store i64 0, i64* %data_ptr63, align 8
> >>
> >> might clobber the loaded location so we do not reuse the first
load. You
> >> use alias metadata in IR or
> >>
> >> `noalias` (in IR) [= `restrict` (in C/C++)] attributes for
arguments to
> >> help the alias analysis.
> >>
> >>
> >> Is this what you were looking for?
> >>
> >>
> >> ~ Johannes
> >>
> >>
> >> On 7/23/20 10:25 AM, Terry Guo via llvm-dev wrote:
> >>> Hi there,
> >>>
> >>> The raw input IR is composed by my tool and the below one is
produced
> by
> >>> llvm opt tool with O3 optimization level. I am pretty sure
that the two
> >>> load instructions( %mem_base60 and %mem_base66) are
referring to the
> >> same
> >>> memory location. How can I instruct llvm optimization pass to
optimize
> >> out
> >>> the %mem_base66 and make the subsequent code reuse the
%mem_base60? I
> >>> tried with metadata 'alias.scope' and
'noalias' and it doesn't help.
> >> Thanks
> >>> for any advice.
> >>>
> >>> 392542 check_exce_succ59: ;
preds > >>> %check_exce_succ40
> >>> **392543 %mem_base60 = load i8*, i8** %mem_base_addr_ptr,
align 8
> >>> 392544 %offset161 = add i32 %call56, 4
> >>> 392545 %11 = sext i32 %offset161 to i64
> >>> 392546 %maddr62 = getelementptr inbounds i8, i8*
%mem_base60, i64 %11
> >>> 392547 %data_ptr63 = bitcast i8* %maddr62 to i64*
> >>> 392548 store i64 0, i64* %data_ptr63, align 8
> >>> **392549 %mem_base66 = load i8*, i8** %mem_base_addr_ptr,
align 8
> >>> 392550 %offset167 = add i32 %call56, 12
> >>> 392551 %12 = sext i32 %offset167 to i64
> >>> 392552 %maddr68 = getelementptr inbounds i8, i8*
%mem_base66, i64 %12
> >>> 392553 %data_ptr69 = bitcast i8* %maddr68 to i32*
> >>> 392554 store i32 %call, i32* %data_ptr69, align 8
> >>>
> >>> BR,
> >>> Terry
> >>>
> >>>
> >>> _______________________________________________
> >>> LLVM Developers mailing list
> >>> llvm-dev at lists.llvm.org
> >>> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20200724/c15961e3/attachment-0001.html>