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

[Terry Guo via llvm-dev]

Hi Johannes,

Sorry for the typo. I meant 'Silly me'.

BR,
Terry

On Fri, Jul 24, 2020 at 12:15 AM Terry Guo <flameroc at gmail.com> wrote:

>   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/ed316799/attachment.html>