This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] PR 62173, re-shuffle insns for RTL loop invariant hoisting

On 05/21/2015 02:46 PM, Jiong Wang wrote:

Thanks for these thoughts.

I tried but still can't prove this transformation will not introduce
extra pointer overflow even given it's reassociation with vfp, although
my first impression is it do will not introduce extra risk in real

Have done a quick check on hppa's legitimize_address. I see for (plus
sym_ref, const_int), if const_int is beyond +-4K, then that hook will
force them into register, then (plus reg, reg) is always OK.
I'm virtually certain the PA's legitimize_address is not overflow safe. It was written long before we started worrying about overflows in address computations. It was mostly concerned with trying generate good addressing modes without running afoul of the implicit space register selection issues.

A SYMBOL_REF is always a valid base register. However, as the comment in hppa_legitimize_address notes, we might be given a MEM for something like: x[n-100000].

We don't want to rewrite that as (x-100000) + n, even though doing so would be beneficial for LICM.

So for target hooks,  my understanding of your idea is something like:

  new hook targetm.pointer_arith_reassociate (), if return -1 then
  support full reassociation, 0 for limited, 1 for should not do any
  reassociation. the default version return -1 as most targets are OK to
  do reassociation given we can prove there is no introducing of overflow
  risk. While for target like HPPA, we should define this hook to return
  0 for limited support.
Right. Rather than use magic constants, I'd suggest an enum for the tri-state. FULL_PTR_REASSOCIATION, PARTIAL_PTR_REASSOCIATION, NO_PTR_REASSOCIATION.

  Then, if targetm.pointer_arith_reassociate () return 1, we should
  further invoke the second hook targetm.limited_reassociate_p (rtx x),
  to check the reassociated rtx 'x' meets any restrictions, for example
  for HPPA, constants part shouldn't beyond +-4K.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]