This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
RE: [PATCH, AArch64] Allow symbol+offset even if not being used for memory access
- From: "Ian Bolton" <ian dot bolton at arm dot com>
- To: "'Richard Henderson'" <rth at redhat dot com>
- Cc: <gcc-patches at gcc dot gnu dot org>
- Date: Thu, 6 Sep 2012 16:06:55 +0100
- Subject: RE: [PATCH, AArch64] Allow symbol+offset even if not being used for memory access
- References: <000001cd8787$dd7f13c0$987d3b40$@bolton@arm.com> <5040DE4F.8010301@redhat.com>
> On 2012-08-31 07:49, Ian Bolton wrote:
> > +(define_split
> > + [(set (match_operand:DI 0 "register_operand" "=r")
> > + (const:DI (plus:DI (match_operand:DI 1 "aarch64_valid_symref"
> "S")
> > + (match_operand:DI 2 "const_int_operand"
> "i"))))]
> > + ""
> > + [(set (match_dup 0) (high:DI (const:DI (plus:DI (match_dup 1)
> > + (match_dup 2)))))
> > + (set (match_dup 0) (lo_sum:DI (match_dup 0)
> > + (const:DI (plus:DI (match_dup 1)
> > + (match_dup 2)))))]
> > + ""
> > +)
>
> You ought not need this as a separate split, since (CONST ...) should
> be handled exactly like (SYMBOL_REF).
I see in combine.c that it does get done for a MEM (which is how my
earlier patch worked), but not when it's being used for other reasons
(hence the title of this email).
See below for current code from find_split_point:
case MEM:
#ifdef HAVE_lo_sum
/* If we have (mem (const ..)) or (mem (symbol_ref ...)), split it
using LO_SUM and HIGH. */
if (GET_CODE (XEXP (x, 0)) == CONST
|| GET_CODE (XEXP (x, 0)) == SYMBOL_REF)
{
enum machine_mode address_mode
= targetm.addr_space.address_mode (MEM_ADDR_SPACE (x));
SUBST (XEXP (x, 0),
gen_rtx_LO_SUM (address_mode,
gen_rtx_HIGH (address_mode, XEXP (x, 0)),
XEXP (x, 0)));
return &XEXP (XEXP (x, 0), 0);
}
#endif
If I don't use my split pattern, I could alter combine to remove the
requirement that parent is a MEM.
What do you think?
>
> Also note that constraints ("=r" etc) aren't used for splits.
>
If I keep the pattern, I will remove the constraints. Thanks for the
pointers in this regard.
Cheers,
Ian