This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: [tree-ssa][PATCH] Let remove_stmt not always remoev annotations(was Re: [tree-ssa]: Code movement is a pain in the ass.)
On Mon, 11 Aug 2003, Andrew MacLeod wrote:
> On Mon, 2003-08-11 at 16:39, Daniel Berlin wrote:
> >
> >
> > On Mon, 11 Aug 2003, Daniel Berlin wrote:
> >
>
> > Actually, doing it this way is going to make bsi_remove a do nothing
> > function that is only a single line wrapper for the new function. This
> > seems odd all not to just add a parameter.
> >
> I know, but when you are dealing with a client API, the second parameter
> is going to serve no purpose...
Except there are other times you might want to do this, and then
you've got to go write another bsi fnuction for those too.
>bsi_remove should remove the stmt the
> iterator points to.
Right. So why does it *also* decide to flub the annotations in that
statement while doing it (not just the statement annotation, it updates
definitions of variables in that statement)?
This is a completely different thing that is not related to removing
a statement.
>Adding a flag to adjust internal only things merely
> obfuscates it. Anyone going to use it or read the code is going to have
> to go and lookup what the flag does. Much cleaner to let bsi_remove
> simply have one parameter. Plus then you dont go changing any client
> code, which is really the point to having an API in the first place.
>
Except when the API does nothing like what you would expect. Would you
have guessed that bsi_remove, documented to remove a statement, would
modify your statement's SSA_NAME's as well?
I didn't.
> I also wouldn't call it bsi_remove_real, that seems a little bit >
flippant :-). Besides, it would require extra reading to figure out
> which one you need... :-)
Other than the name, can i commit the patch?