This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Dealing with paradoxical subregs of memory?


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]