This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: [RFC] Further LRA subreg handling issues
- From: Eric Botcazou <ebotcazou at adacore dot com>
- To: Matthew Fortune <Matthew dot Fortune at imgtec dot com>
- Cc: gcc at gcc dot gnu dot org, Vladimir Makarov <vmakarov at redhat dot com>, Richard Sandiford <rdsandiford at googlemail dot com>, "Jeff Law <law at redhat dot com> (law at redhat dot com)" <law at redhat dot com>
- Date: Thu, 26 Jan 2017 23:33:36 +0100
- Subject: Re: [RFC] Further LRA subreg handling issues
- Authentication-results: sourceware.org; auth=none
- References: <6D39441BF12EF246A7ABCE6654B0235380B2A969@HHMAIL01.hh.imgtec.org> <27010526.iI87GVC0sX@polaris> <6D39441BF12EF246A7ABCE6654B0235380B3B101@HHMAIL01.hh.imgtec.org>
> This part suggests to me that LRA should never be reloading the
> paradoxical subreg meaning the whole SLOW_UNALIGNED_ACCESS checking code in
> simplify_operand_subreg could be removed unconditionally.
Why? For a little-endian target which is neither strict-alignment nor
WORD_REGISTER_OPERATIONS, typically x86, you can reload the outer reg.
Problems arise only for big-endian or strict-alignment or W_R_O, as explained
by the find_reloads code.
IOW simplify_operand_subreg should mimic the handling of paradoxical SUBREGs
done by find_reloads, with specific checks for WORD_REGISTER_OPERATIONS,
BYTES_BIG_ENDIAN, etc.
> Eric: I see you recently had to modify the code I'm talking about in the
> post below. Out of interest... was this another issue brought to light by
> the improvements to zero extension elimination?
Nope, there were a couple of other, unrelated bugs in the code.
--
Eric Botcazou