[Bug middle-end/92308] New: Gimple passes could do a better job of forming address CSEs

[rearnsha at gcc dot gnu.org]

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

            Bug ID: 92308
           Summary: Gimple passes could do a better job of forming address
                    CSEs
           Product: gcc
           Version: 10.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: middle-end
          Assignee: unassigned at gcc dot gnu.org
          Reporter: rearnsha at gcc dot gnu.org
  Target Milestone: ---

Consider this testcase which was mentioned in
https://gcc.gnu.org/ml/gcc-help/2019-10/msg00122.html.  

#define BB_ADDRESS 0x43fe1800

void test1(void) {
  volatile uint32_t * const p = (uint32_t *) BB_ADDRESS;

  p[3] = 1;
  p[4] = 2;
  p[1] = 3;
  p[7] = 4;
  p[0] = 6;
}

The gimple generated for this is

test1 ()
{
;;   basic block 2, loop depth 0
;;    pred:       ENTRY
  MEM[(volatile uint32_t *)1140725772B] ={v} 1;
  MEM[(volatile uint32_t *)1140725776B] ={v} 2;
  MEM[(volatile uint32_t *)1140725764B] ={v} 3;
  MEM[(volatile uint32_t *)1140725788B] ={v} 4;
  MEM[(volatile uint32_t *)1140725760B] ={v} 6;
  return;
;;    succ:       EXIT

}

However, it's very unlikely on any RISC type architecture that addresses of
this form will be valid.  The TARGET_LEGITIMIZE_ADDRESS hook can help here, but
that has to guess how to split the address and it has no idea what, for each
call, the best base that should be chosen.  In this case the best base is
likely to be the lowest addressed object in the sequence, so that all other
objects can use a small positive offset from that.

The GIMPLE passes have a much broader view on the code being optimized, so
forming a common base for all these addresses should be straight forward and
much more likely to lead to better code than having to use a heuristic in the
back-end.