[Bug target/95078] New: Missing fwprop for SIB address

[Bug target/95078] New: Missing fwprop for SIB address

[crazylht at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95078

            Bug ID: 95078
           Summary: Missing fwprop for SIB address
           Product: gcc
           Version: 11.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: target
          Assignee: unassigned at gcc dot gnu.org
          Reporter: crazylht at gmail dot com
                CC: hjl.tools at gmail dot com
  Target Milestone: ---
            Target: i386, x86-64

cat test.c

int foo (int* p1, int* p2, int scale)
{
    int ret = *(p1 + scale * 4 + 11);
    *p2 = 3;
    int ret2 = *(p1 + scale * 4 + 11);
    return ret + ret2;
}

gcc11 -O2 test.c -S 

foo(int*, int*, int):
        sall    $2, %edx
        movslq  %edx, %rdx
        leaq    44(%rdi,%rdx,4), %rdx  --- redundant could be fwprop
        movl    (%rdx), %eax
        movl    $3, (%rsi)
        addl    (%rdx), %eax
        ret

fwprop failed to propagate this because it think cost of address
44(%rdi,%rdx,4) is more expensive than (%rdx), that's correct locally, but
under global view, if it could be propagated into both movl, leaq would be
eliminated, which benifits performance.

The ideal place to handle this issue is TER opt in pass_expand, but currently
TER only handle simple situation ---- single use and block level

 48   A pass is made through the function, one block at a time.  No cross block 
 49   information is tracked.                                                   
 50                                                                             
 51   Variables which only have one use, and whose defining stmt is considered  
 52   a replaceable expression (see ssa_is_replaceable_p) are tracked to see
whether                                                                         
 53   they can be replaced at their use location.       

Should TER be extended?

Another testcase has this issue in more complex cfg

Refer to
https://godbolt.org/z/ofjH9R

[Bug target/95078] Missing fwprop for SIB address

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95078

--- Comment #1 from Richard Biener <rguenth at gcc dot gnu.org> ---
TER should go away, not be extended.  So you are suggesting that we replace

        leaq    44(%rdi,%rdx,4), %rdx  --- redundant could be fwprop
        movl    (%rdx), %eax
        movl    $3, (%rsi)
        addl    (%rdx), %eax

with

        movl   44(%rdi,%rdx,4), %eax
        movl    $3, (%rsi)
        addl   44(%rdi,%rdx,4), %eax

?  The variant that looks bigger is actually one byte smaller.  Note as
soon as there are three uses it will be larger again...

So this is really something for RTL and yeah, fwprop only makes "local"
decisions.  Note that I think that your proposed variant will consume
more resources since the complex addressing modes are likely split into
a separate uop.  Yes, overall I'd expect less latency for your sequence.

[Bug target/95078] Missing fwprop for SIB address

[crazylht at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95078

--- Comment #2 from Hongtao.liu <crazylht at gmail dot com> ---
(In reply to Richard Biener from comment #1)
> TER should go away, not be extended.  So you are suggesting that we replace
> 
>         leaq    44(%rdi,%rdx,4), %rdx  --- redundant could be fwprop
>         movl    (%rdx), %eax
>         movl    $3, (%rsi)
>         addl    (%rdx), %eax
> 
> with
> 
>         movl   44(%rdi,%rdx,4), %eax
>         movl    $3, (%rsi)
>         addl   44(%rdi,%rdx,4), %eax
> 
Yes.
> ?  The variant that looks bigger is actually one byte smaller.  Note as
> soon as there are three uses it will be larger again...
> 
> So this is really something for RTL and yeah, fwprop only makes "local"
> decisions.  Note that I think that your proposed variant will consume
> more resources since the complex addressing modes are likely split into
> a separate uop.  Yes, overall I'd expect less latency for your sequence.
Yes, also it will increase register pressure since propagation mostly would
increase live range for base and index reg, it's a subtle optimization, maybe 
a cost model could help, and fwprop should be more "smart" to see the
redundance of adress calculation after propagation.