[llvm-dev] How to optimize out the duplicated memory load instructions?

[Terry Guo via llvm-dev]

  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>