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]: Code movement is a pain in the ass.

On Sun, 2003-08-10 at 14:01, Daniel Berlin wrote:
> On Sunday, August 10, 2003, at 1:11 PM, Diego Novillo wrote:
> > On Sun, 2003-08-10 at 01:42, Daniel Berlin wrote:
> >
> >> Anybody mind if i make bsi_remove take an argument to convince it i'm
> >> only removing the statement temporarily (ie moving it), and then add
> >> an argument to  remove_stmt to tell it *not* to reset definitions and
> >> annotations?
> >>
> >> That way, i can just remove it from one place, and move it to another?
> >>
> > Or, how about we create a bsi_move (stmt, from, to)?  'from' and 'to'
> > may be iterators or some structure that includes enough info to remap
> > the statement from the old location into the new one.
> Ideally, it would still use bsi_remove and bsi_insert_after/before 
> internally, so we'd still need to be able to tell bsi_remove and 
> remove_stmt to not invalidate definitions.
> Otherwise we end up copying code from remove_stmt, which seems silly 
> when we can just surround 20 lines of it with a if (update_annotations) 
> and have it take an extra argument.
I meant implementing bsi_move in terms of bsi_remove and bsi_insert.  Is
that feasible?


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