This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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?

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]