[PowerPC] Fix pr25212
Ian Lance Taylor
ian@airs.com
Mon Dec 5 03:03:00 GMT 2005
Alan Modra <amodra@bigpond.net.au> writes:
> This patch provides a function that returns the reg class of an input
> reload for a given piece of rtl, allowing address and memory predicates
> to see what is happening in reload. I use this in
> legitimate_indexed_address_p to match addresses that have already had
> some reloads, catching more cases than my fix for PR24997.
>
> While fiddling with this patch, I noticed that INT_REG_OK_FOR_BASE_P can
> return true for a pseudo reg that has reg_renumber[REGNO] == 0, so I
> fixed this problem too. Bootstrap and regression tests on powerpc-linux
> and powerpc64-linux in progress. OK for mainline and 4.1 assuming no
> regressions? (If input_reload_for doesn't seem generally useful, I can
> move it to rs6000.c.)
>
> :ADD_PATCH target, middle-end:
>
> PR target/25212
> * reload.c (input_reload_for): New function.
> * reload.h (input_reload_for): Prototype.
> * config/rs6000/rs6000.c (is_base_index): New function.
> (legitimate_indexed_address_p): Use is_base_index.
> * config/rs6000/rs6000.h (INT_REG_OK_FOR_INDEX_P): Simplify.
> (INT_REG_OK_FOR_BASE_P): Correct.
This is only going to work if you know for sure that during any call
to memory_address_p or strict_memory_address_p during reload the
n_reloads and rld variables will be initialized properly for the
instruction containing the address which is being checked. Do we
really know that? For example, find_reloads will reset n_reloads to 0
at the start of the function. It can then call memory_address_p (via,
e.g., find_reloads_toplev) before n_reloads has been restored to its
old value. But some of the addresses in the instruction may be being
reloaded, due to a previous call to find_reloads.
So it seems to me that input_reload_for is not reliable.
If LEGITIMIZE_RELOAD_ADDRESS can transform the address, then it is
clearly useful to know how that has been done. But I don't think the
approach you are proposing will work.
Ian
More information about the Gcc-patches
mailing list