<div dir="ltr"><span style="font-size:small;text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline">Andres:</span><div style="font-size:small;text-decoration-style:initial;text-decoration-color:initial"><br></div><div style="font-size:small;text-decoration-style:initial;text-decoration-color:initial">FWIW, codegen will do the merge if you turn on global alias analysis for it "-combiner-global-alias-analysis". That said, we should be able to do this merging earlier. </div><div style="font-size:small;text-decoration-style:initial;text-decoration-color:initial"><br></div><div style="font-size:small;text-decoration-style:initial;text-decoration-color:initial">-Nirav</div><div style="font-size:small;text-decoration-style:initial;text-decoration-color:initial"><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Sep 10, 2018 at 8:33 PM, Andres Freund via llvm-dev <span dir="ltr"><<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br>
<div><div class="h5"><br>
On 2018-09-10 13:42:21 -0700, Andres Freund wrote:<br>
> I have, in postres, a piece of IR that, after inlining and constant<br>
> propagation boils (when cooked on really high heat) down to (also<br>
> attached for your convenience):<br>
> <br>
> source_filename = "pg"<br>
> target datalayout = "e-m:e-i64:64-f80:128-n8:16:<wbr>32:64-S128"<br>
> target triple = "x86_64-pc-linux-gnu"<br>
> <br>
> define void @evalexpr_0_0(i8* align 8 noalias, i32* align 8 noalias) {<br>
> entry:<br>
>   %a01 = getelementptr i8, i8* %0, i16 0<br>
>   store i8 0, i8* %a01<br>
> <br>
>   ; in the real case this also loads data<br>
>   %b01 = getelementptr i32, i32* %1, i16 0<br>
>   store i32 0, i32* %b01<br>
> <br>
>   %a02 = getelementptr i8, i8* %0, i16 1<br>
>   store i8 0, i8* %a02<br>
> <br>
>   ; in the real case this also loads data<br>
>   %b02 = getelementptr i32, i32* %1, i16 1<br>
>   store i32 0, i32* %b02<br>
> <br>
>   ; in the real case this also loads data<br>
>   %a03 = getelementptr i8, i8* %0, i16 2<br>
>   store i8 0, i8* %a03<br>
> <br>
>   ; in the real case this also loads data<br>
>   %b03 = getelementptr i32, i32* %1, i16 2<br>
>   store i32 0, i32* %b03<br>
> <br>
>   %a04 = getelementptr i8, i8* %0, i16 3<br>
>   store i8 0, i8* %a04<br>
> <br>
>   ; in the real case this also loads data<br>
>   %b04 = getelementptr i32, i32* %1, i16 3<br>
>   store i32 0, i32* %b04<br>
> <br>
>   ret void<br>
> }<br>
<br>
</div></div><span class="">> So, here we finally come to my question: Is it really expected that,<br>
> unless largely independent optimizations (SLP in this case) happen to<br>
> move instructions *within the same basic block* out of the way, these<br>
> stores don't get coalesced?  And then only if the either the<br>
> optimization pipeline is run again, or if instruction selection can do<br>
> so?<br>
> <br>
> <br>
> On IRC Roman Lebedev pointed out <a href="https://reviews.llvm.org/D48725" rel="noreferrer" target="_blank">https://reviews.llvm.org/<wbr>D48725</a> which<br>
> might address this indirectly.  But I'm somewhat doubtful that that's<br>
> the most straightforward way to optimize this kind of code?<br>
<br>
</span>That doesn't help, but it turns out that //<a href="http://reviews.llvm.org/D30703" rel="noreferrer" target="_blank">reviews.llvm.org/D30703</a> can<br>
kinda somwhat help by adding a redundant<br>
  %i32ptr = bitcast i8* %0 to i32*<br>
  store i32 0, i32* %i32ptr<br>
<br>
at the start. Then dse-partial-store-merging does its magic and<br>
optimizes the sub-stores away.  But it's fairly ugly to manually have to<br>
add superflous stores in the right granularity (a larger llvm.memset<br>
doesn't work).<br>
<br>
gcc, since 7, detects such cases in its "new" -fstore-merging pass.<br>
<br>
- Andres<br>
______________________________<wbr>_________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/<wbr>mailman/listinfo/llvm-dev</a><br>
</blockquote></div><br></div>