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: VREGS cannot handle subreg(mem (plus ...)) pattern

From: Claudiu Zissulescu <Claudiu dot Zissulescu at synopsys dot com>
To: Jeff Law <law at redhat dot com>, "gcc at gcc dot gnu dot org" <gcc at gcc dot gnu dot org>
Cc: Francois Bedard <Francois dot Bedard at synopsys dot com>
Date: Tue, 11 Oct 2016 15:54:49 +0000
Subject: RE: VREGS cannot handle subreg(mem (plus ...)) pattern
Authentication-results: sourceware.org; auth=none
References: <098ECE41A0A6114BB2A07F1EC238DE89661B82DF@de02wembxa.internal.synopsys.com> <efe3c744-6dd2-a0a8-0e24-e26c85da8436@redhat.com>

Hi Jeff,

> IIRC you're not supposed to have (subreg (mem)) expressions at this point.
> 
> Any (subreg (mem)) at this point can be trivially turned into a simple
> memory load.
> 
The issue is that the mode_dependent_address_p hook returns true, thus the simplify_subreg() will not simplify the subref(mem) as expected (see simplify-rtx.c:6045). Everything boils down in having the subreg(mem) while expanding (via simplify_gen_subreg -> emit_store_flag_1).

So, a solution (also which I applied a while back) is to relax ARC's mode_dependent_address_p  hook avoiding in this way the above issue. Not very sure about it though.

Thanks,
Claudiu

References:
- VREGS cannot handle subreg(mem (plus ...)) pattern
  - From: Claudiu Zissulescu
- Re: VREGS cannot handle subreg(mem (plus ...)) pattern
  - From: Jeff Law

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