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

Jeff Law law@redhat.com
Wed May 27 16:11:00 GMT 2015


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
> application.
>
> 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.
Right.

Jeff



More information about the Gcc-patches mailing list