This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: Alias changes
- To: law at cygnus dot com
- Subject: Re: Alias changes
- From: Mark Mitchell <mark at markmitchell dot com>
- Date: Thu, 25 Jun 1998 10:49:58 -0700
- CC: egcs-patches at cygnus dot com
- References: <26963.898756190@hurl.cygnus.com>
- Reply-to: mark at markmitchell dot com
>>>>> "Jeffrey" == Jeffrey A Law <law@hurl.cygnus.com> writes:
Jeffrey> I'd prefer to have this option off by default for the
Jeffrey> short term; just call me Mr. Conservative. I'll
Dear Mr. Conservative :-)
Jeffrey> personally be trying it, but I'm a little uncomfortable
Jeffrey> having it be on by default for the upcoming release.
Fine.
Jeffrey> Somewhere in the rtl/tree changes you should note that
Jeffrey> the alias set is just an integer and does not directly
Jeffrey> correspond to a particular type, storage class, memory
Jeffrey> location, etc. That's a pretty fundamental concept that
Jeffrey> needs a mention somewhere (if I missed it, then ignore my
Jeffrey> comment).
OK.
Jeffrey> I think we need to save/restore the current alias set #
Jeffrey> as we change function contexts so that the current alias
Jeffrey> set # isn't scrogged when we compile a nested function.
Jeffrey> Even if this isn't an issue right now we need to go ahead
Jeffrey> and save/restore the set #. It's simple to do, so I
Jeffrey> don't think you need to resubmit after making this
Jeffrey> change.
I don't quite get this. With my patch, the C front-end assigns alias
sets to types lazily, as it creates MEMs who need alias sets. It
doesn't make sense to have different types in the same alias set, so I
don't see why we'd ever want to restore the alias set counter to a
previous value. It should monotonically increase, I think.
Jeffrey> We've already discussed the long vs int stuff.
Yup, got it.
Jeffrey> I think you should install the patch after making the
Jeffrey> changes noted above.
Thanks. I'm going to go ahead and do that, but *without* the
save/restore across function contexts. I'll be happy to go ahead and
add that if you convince me it's needed.
Jeffrey> jeff
--
Mark Mitchell mark@markmitchell.com
Mark Mitchell Consulting http://www.markmitchell.com