This is the mail archive of the
mailing list for the GCC project.
Re: [PATCH] PR 62173, re-shuffle insns for RTL loop invariant hoisting
- From: Jeff Law <law at redhat dot com>
- To: Jiong Wang <jiong dot wang at arm dot com>
- Cc: Steven Bosscher <stevenb dot gcc at gmail dot com>, "gcc-patches at gcc dot gnu dot org" <gcc-patches at gcc dot gnu dot org>, Kenneth Zadeck <zadeck at naturalbridge dot com>
- Date: Wed, 27 May 2015 10:04:51 -0600
- Subject: Re: [PATCH] PR 62173, re-shuffle insns for RTL loop invariant hoisting
- Authentication-results: sourceware.org; auth=none
- References: <54803EBE dot 2060607 at arm dot com> <5480B6D6 dot 2020201 at arm dot com> <548EFE0D dot 1070808 at arm dot com> <548EFE55 dot 6090901 at arm dot com> <CAFiYyc3oYRsYkQwivE+T4A4mysDBe0gjZqjroQ8B2p1J6sakQg at mail dot gmail dot com> <54930811 dot 1020003 at arm dot com> <20141218220908 dot GA20720 at gate dot crashing dot org> <CAHFci28ajc8KqKEvyYYvQHbhYkZ-ExV8ixJ+SNuqV8bg3n7JJQ at mail dot gmail dot com> <CAAfDdZ0EZ6EVN_wYFFuh81ptL2c_Em-Ub-2s4GO7Vp0QKjd-=Q at mail dot gmail dot com> <CAFiYyc32CJJTjakxMLjkCQAJLrv1u0PSjifTs=A4V4q4nOFTKg at mail dot gmail dot com> <5494426A dot 9010209 at naturalbridge dot com> <CAAfDdZ2xrfRYoD8eO1L+8StWh53OhFNBy4ZMRt-K4xSj6r64eA at mail dot gmail dot com> <54DB6587 dot 1020207 at naturalbridge dot com> <54DB9CDB dot 5090304 at arm dot com> <CAAfDdZ29jHnFFGCpi8Adgf4hXk80QQH-vCrV=m0wdZNkT0x84A at mail dot gmail dot com> <CABu31nPMZ5ZCx+frisV+AT9pmC+DumN+Sjt=UscZ48kze4_3YQ at mail dot gmail dot com> <552D4D61 dot 9040100 at redhat dot com> <CAAfDdZ1G_0A0k0RRF2XO_5W6xN13BoA_18+s-Z68P1YTS! 32mMA at mail dot gmail dot com> <n99siayal1i dot fsf at arm dot com> <55551FD7 dot 6070805 at redhat dot com> <n99mw0xaa4w dot fsf at arm dot com>
On 05/21/2015 02:46 PM, Jiong Wang wrote:
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
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.
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
We don't want to rewrite that as (x-100000) + n, even though doing so
would be beneficial for LICM.
Right. Rather than use magic constants, I'd suggest an enum for the
tri-state. FULL_PTR_REASSOCIATION, PARTIAL_PTR_REASSOCIATION,
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.
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.