This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: RFA: enable LRA for rs6000
- From: David Edelsohn <dje dot gcc at gmail dot com>
- To: Vladimir Makarov <vmakarov at redhat dot com>
- Cc: gcc-patches <gcc-patches at gcc dot gnu dot org>, Michael Meissner <meissner at linux dot vnet dot ibm dot com>, "Bergner, Peter" <bergner at vnet dot ibm dot com>
- Date: Fri, 12 Apr 2013 19:38:46 -0400
- Subject: Re: RFA: enable LRA for rs6000
- References: <5166F34C dot 30901 at redhat dot com> <CAGWvny=c9MhDj61jApoAJoZKjZyoE_eiNy1KpfxnWPF5h2dDzA at mail dot gmail dot com> <51672576 dot 1040305 at redhat dot com> <51683CEC dot 5040301 at redhat dot com>
On Fri, Apr 12, 2013 at 12:57 PM, Vladimir Makarov <vmakarov@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