This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: subreg rtl documentation
- From: Jeff Law <law at redhat dot com>
- To: Kenneth Zadeck <zadeck at naturalbridge dot com>
- Cc: Jim Wilson <wilson at tuliptree dot org>, 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: Wed, 09 Apr 2008 01:42:21 -0600
- 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> <1207672710.3224.11.camel@localhost.localdomain> <47FBA1C0.7060605@redhat.com> <47FBAE46.5040304@naturalbridge.com> <47FBB901.4040606@redhat.com> <47FBCD71.9090103@naturalbridge.com>
Kenneth Zadeck wrote:
I was just kidding. i understand why you were being vague. i knew it
was not to hide anything.
No worries.
It sounds like you (plural) are tentatively saying that if we made the
same statements about subregs of mem after reload, we would be on ground
that the community would be willing to support. That does not mean that
anyone plans to submit patches to break this, but it gives us a basis to
review things going forward.
So the vagueness simply needs to have a sense of purpose. It is ok to
say this is an old edge of the compiler that no one understands and we
would like to see go away. So if you want to exploit some feature of
this, good luck.
I'd lean more towards the crisper definition we're hammering out with
some checks to ensure things don't go haywire. If you chose to go with
the squishy version, then I'd probably go with two main ideas.
1. Current semantics we're pretty sure we've nailed down.
2. Current semantics which are squishy
2a. Explicit note that squishy semantics are likely to change
2b. Where we hope the squishy semantics will go in the future
(and at which point they turn into hard semantics).
And just to be absolutely clear, I'm jumping for joy to see this stuff
being hammered out and documented.
Jeff