On Fri, Apr 12, 2013 at 12:57 PM, Vladimir Makarov <vmaka...@redhat.com> wrote:
> After thorough investigation I found that this code is still ok. The
> explanations are in the comment. Here is the modified version of the code
> taking you proposals into account
>
> @@ -5701,19 +5705,31 @@ legitimate_lo_sum_address_p (enum machin
>
> if (TARGET_ELF || TARGET_MACHO)
> {
> + bool large_toc_ok;
> +
> if (DEFAULT_ABI != ABI_AIX && DEFAULT_ABI != ABI_DARWIN && flag_pic)
> return false;
> - if (TARGET_TOC)
> + /* LRA don't use LEGITIMIZE_RELOAD_ADDRESS as it usually calls
> + push_reload from reload pass code. LEGITIMIZE_RELOAD_ADDRESS
> + recognizes some LO_SUM addresses as valid although this
> + function says opposite. In most cases, LRA through different
> + transformations can generate correct code for address reloads.
> + It can not manage only some LO_SUM cases. So we need to add
> + code analogous to one in rs6000_legitimize_reload_address for
> + LOW_SUM here saying that some addresses are still valid. */
> + large_toc_ok = (lra_in_progress && TARGET_CMODEL != CMODEL_SMALL
>
> + && small_toc_ref (x, VOIDmode));
> + if (TARGET_TOC && ! large_toc_ok)
> return false;
> if (GET_MODE_NUNITS (mode) != 1)
> return false;
> - if (GET_MODE_SIZE (mode) > UNITS_PER_WORD
> + if (! lra_in_progress && GET_MODE_SIZE (mode) > UNITS_PER_WORD
> && !(/* ??? Assume floating point reg based on mode? */
> TARGET_HARD_FLOAT && TARGET_FPRS && TARGET_DOUBLE_FLOAT
> && (mode == DFmode || mode == DDmode)))
> return false;
>
> - return CONSTANT_P (x);
> + return CONSTANT_P (x) || large_toc_ok;
> }
>
> return false;
Okay, this makes more sense.
I think that Mike is running some experiments with LRA to see what
impact we see. I would like to understand that a little more before
we apply the patch to trunk.
Thanks David
