This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
RE: VREGS fails to handle subreg of mem
- From: Claudiu Zissulescu <Claudiu dot Zissulescu at synopsys dot com>
- To: Eric Botcazou <ebotcazou at adacore dot com>
- Cc: "gcc at gcc dot gnu dot org" <gcc at gcc dot gnu dot org>, Francois Bedard <Francois dot Bedard at synopsys dot com>
- Date: Wed, 2 Apr 2014 07:34:36 +0000
- Subject: RE: VREGS fails to handle subreg of mem
- Authentication-results: sourceware.org; auth=none
- References: <098ECE41A0A6114BB2A07F1EC238DE8965277D14 at DE02WEMBXB dot internal dot synopsys dot com> <1403519 dot GBSqIPd5Et at polaris>
Thank you for the feedback. I did found the issue in mode_dependent_address_p hook.
//Claudiu
> -----Original Message-----
> From: Eric Botcazou [mailto:ebotcazou@adacore.com]
> Sent: Monday, March 31, 2014 10:21 PM
> To: Claudiu Zissulescu
> Cc: gcc@gcc.gnu.org; Francois Bedard; claziss@gmail.com
> Subject: Re: VREGS fails to handle subreg of mem
>
> > In our ARC port, we found the following situation after expand:
> >
> > (insn 23 22 24 5 (set (reg:SI 176)
> > (subreg:SI (mem/c:DI (plus:SI (reg/f:SI 147 virtual-stack-vars)
> > (const_int -268 [0xfffffffffffffef4])) [3
> > tmpoutst.st_size+0 S8 A32]) 4)) t02.c:64 -1 (nil))
> >
> > The virtual-stack-vars should be handled by GCC's VREGS step, in
> > instantiate_virtual_regs_in_insn(). However, this is not happening as
> > the subroutine is not designed to handle subregs of a mem. As a
> > consequence, virtual-stack-vars is not eliminated, and the compilation fails
> later on.
> > To solve this issue, I am proposing the attached patch on vregs, that
> > implements handling of such situation by
> > instantiate_virtual_regs_in_insn().
> >
> > Can you please let me know if this is an acceptable solution for the
> > given issue?
>
> Very likely not, there should be no SUBREGs of MEMs after expand.
>
> --
> Eric Botcazou