This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: subreg rtl documentation
- From: Jim Wilson <wilson at tuliptree dot org>
- To: Jeff Law <law at redhat dot com>
- Cc: Kenneth Zadeck <zadeck at naturalbridge dot com>, Kenneth dot Zadeck at naturalbridge dot com, gcc-patches at gcc dot gnu dot org, "Bonzini, Paolo" <bonzini at gnu dot org>, Richard Kenner <kenner at vlsi1 dot ultra dot nyu dot edu>, Bernd Schmidt <bernds_cb1 at t-online dot de>, "Joseph S. Myers" <joseph at codesourcery dot com>, Joern Rennecke <joernr at arc dot com>, rsandifo at nildram dot co dot uk
- Date: Tue, 08 Apr 2008 09:38:30 -0700
- Subject: Re: subreg rtl documentation
- References: <87wsnda8bu.fsf@moria.site> <87ej9l8tad.fsf@firetop.home> <47FA40CC.5070503@naturalbridge.com> <87skxxabop.fsf@firetop.home> <47FA61D3.70504@tuliptree.org> <47FA6A4E.4090208@naturalbridge.com> <47FA6D0F.10703@redhat.com> <47FADCDB.90506@naturalbridge.com> <87ej9gzs13.fsf@firetop.home> <47FB970D.1080706@redhat.com>
On Tue, 2008-04-08 at 10:02 -0600, Jeff Law wrote:
> I don't think we do. reload makes a pass over all the insns calling
> cleanup_subreg_operands which ought to be zapping all the (subreg (mem))
> thingies and replacing (subreg (hardreg)) with (hardreg')
But we also call cleanup_subreg_operands in final_scan_insn, right
before emitting assembly code, which implies that some subregs might be
slipping through.
If we wanted to know for sure, we could put an abort here. Maybe pass
an extra operand to cleanup_subreg_operands, and if it does find a
subreg, abort, and then document or fix the circumstances.
Jim