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
