This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Dealing with paradoxical subregs of memory?
- From: Segher Boessenkool <segher at kernel dot crashing dot org>
- To: vogt at linux dot vnet dot ibm dot com, gcc at gcc dot gnu dot org, Andreas Krebbel <krebbel at linux dot vnet dot ibm dot com>, Ulrich Weigand <Ulrich dot Weigand at de dot ibm dot com>
- Date: Wed, 25 Jan 2017 16:45:23 -0600
- Subject: Re: Dealing with paradoxical subregs of memory?
- Authentication-results: sourceware.org; auth=none
- References: <20170125173604.GA28642@linux.vnet.ibm.com>
On Wed, Jan 25, 2017 at 06:36:04PM +0100, Dominik Vogt wrote:
> What's the matter with paradoxical subregs of memory? So, as far
> as I understand, Recog refuses to match them unless they are
> explicitly expressed as a pattern.
If INSN_SCHEDULING is defined recog does not allow paradoxical subregs
of memory as a general_operand (memory_operand does not allow any
subregs of memory).
> On the other hand, Combine
> does not know that they are "outlawed" and happily generates
> them.
combine should not generate things that can never match. Of course it
sometimes does. This should be improved; please open a PR.
> (set (reg/i:DI 2 %r2)
> (and:DI (subreg:DI (mem:QI (plus:DI (reg:DI 2 %r2 [ f ])
> ^^^^^^^^^^^^^^^^^
> (const_int 2 [0x2])) [1 *f_5(D)+2 S1 A16]) 0)
> (const_int 1 [0x1])))
>
> Which doesn't match because of the paradoxical subreg of memory (I
> think).
>
> Wouldn't it be better to allow that inside combine, then ann a
> pass right after it that forces a reaload into a pseudo for such
> memory references (for the targets that don't want them)? (Not
> sure if theat would result in a noticeable gain or not.)
combine already does this and then tries to split it at that mem; but
in this case (a combination of only two insns) it won't even try to
split.
Segher