On Wed, Mar 17, 2021 at 12:35 AM Thomas Schwinge
<[email protected]> wrote:
>
> Hi!
>
> On 2021-03-17T00:24:55+0100, I wrote:
> > Now, walking each function backwards (!), [...]
>
> > I've now got a simple 'callback_op', which for '!is_lhs' looks at
> > 'get_base_address ([op])', and if that 'var' is contained in the set of
> > current candidates (initialized per containg 'bind's, which we enter
> > first, even if walking a 'gimple_seq' backwards), removes that 'var' as a
> > candidate for such optimization. (Plus some "details", of couse.) This
> > seems to work fine, as far as I can tell. :-)
>
> Is something like the attached "[WIP] 'walk_gimple_seq' backward" OK
> conceptually? (For next development stage 1 and with all the TODOs
> resolved, of course.)
>
> The 'backward' flag cannot simply be a argument to 'walk_gimple_seq'
> etc.: it needs to also be passed to 'walk_gimple_seq_mod' calls triggered
> from inside 'walk_gimple_stmt'. Hence, I've put it into the state
> 'struct walk_stmt_info'.
Can't you simply walk the sequence backward youself and call
walk_gimple_stmt on each stmt instead?
That said,
if (!wi->removed_stmt)
- gsi_next (&gsi);
+ {
+ if (forward)
+ gsi_next (&gsi);
+ else //TODO Correct?
+ gsi_prev (&gsi);
+ //TODO This could do with some unit testing, to make sure
all the corner cases (removing first/last, for example) work
correctly.
+ }
if wi->removed_stmt maps to gsi_remove being called then the backwards
code is incorrect since gsi_remove advances the iterator in the wrong direction.
So you always need gsi_prev () here.
Otherwise sure.
Richard.
>
> Grüße
> Thomas
>
>
> -----------------
> Mentor Graphics (Deutschland) GmbH, Arnulfstrasse 201, 80634 München
> Registergericht München HRB 106955, Geschäftsführer: Thomas Heurung, Frank
> Thürauf
