> -----Ursprüngliche Nachricht-----
> Von: stefan@xxxxxxxxx <stefan@xxxxxxxxx>
> Gesendet: Freitag, 13. September 2019 12:45
> An: 'Richard Sandiford' <richard.sandiford@xxxxxxx>
> Cc: gcc-help@xxxxxxxxxxx
> Betreff: AW: new ira optimization - adding a loop to ira
>
> > -----Ursprüngliche Nachricht-----
> > Von: Richard Sandiford <richard.sandiford@xxxxxxx>
> > Gesendet: Freitag, 13. September 2019 12:16
> > An: stefan@xxxxxxxxx
> > Cc: gcc-help@xxxxxxxxxxx
> > Betreff: Re: new ira optimization - adding a loop to ira
> >
> > <stefan@xxxxxxxxx> writes:
> > > I'm working on a new optimization to get rid of spilled tmp
> > > variables
> (e.g.
> > > introduced by pre) to use the source mem ref instead of a stack slot.
> > >
> > > To do this, I added a loop into ira.c:ira()
> > >
> > > init_prune_stack_vars ();
> > > do
> > > {
> > > #ifndef IRA_NO_OBSTACK
> > > gcc_obstack_init (&ira_obstack);
> > > #endif
> > > bitmap_obstack_initialize (&ira_bitmap_obstack);
> > >
> > > ...
> > >
> > > ira_color ();
> > >
> > > }
> > > while (flag_prune_stack_vars && prune_stack_vars ());
> > >
> > > To get it work, the prune_stack_vars function resets a couple of data.
> > > This is mostly working - but on some source files, it fails due to
> > > invalid reg_equivs.
> > > Since this also happens, if the optimizer does nothing and just
> > > loops
> once.
> > >
> > > Currently I'm calling this, before looping again
> > >
> > > regstat_free_n_sets_and_refs ();
> > > regstat_free_ri ();
> > > loop_optimizer_finalize ();
> > > free_dominance_info (CDI_DOMINATORS);
> > >
> > > Any hint, what I'm missing to reset?
> >
> > I can't see anything obviously missing. What kind of failure do you
> see? E.g.
> > do you get an internal compiler error or does the compiler generate
> > incorrect code?
> >
> > Do you see the failure on an in-tree test case? FWIW, I just tried
> looping like
> > this locally and didn't see any failures for the tests I tried. But I
> was obviously
> > testing without the new optimisation, and so each loop iteration
> > should
> just
> > repeat what the previous one did.
> >
> > Not related to the failure, but: do you do anything with the obstacks
> when
> > looping again? Including the initialisations in the loop as above
> > would introduce a memory leak if you don't do anything to free the
> contents.
> > It'd probably be better to initialise outside the loop unless you're
> really
> > confident that the no data is carried across iterations.
> >
> > Thanks,
> > Richard
>
> Thanks für the ira_obstack hint - I will take care of this, once the loop
mode
> is working - maybe I can start looping later or I'll free the memory.
>
> In reload: push_reload(...) this raises an error:
>
> gcc_assert (regno < FIRST_PSEUDO_REGISTER
> || reg_renumber[regno] >= 0
> || reg_equiv_constant (regno) == NULL_RTX);
>
> I already know that it's reg_equiv_constant and that this
reg_equiv_constant
> is also set in the unpatched code.
>
> So I am looking why these additional reloads occur. There are additional
> reloads if I enable the loop, interestingly for uid like 2, 3, 4 ...
>
> Thanks,
> Stefan
The difference is the additional expr_list, which causes the reload:
(insn 2 10 3 2 (set (reg/f:SI 9 a1 [orig:46 this ] [46])
(mem/f/c:SI (plus:SI (reg/f:SI 15 sp)
(const_int 16 [0x10])) [178 this+0 S4 A16]))
engines/sci/engine/kpathing.cpp:758 40 {*movsi_m68k2}
(expr_list:REG_EQUIV (mem/f/c:SI (plus:SI (reg/f:SI 15 sp)
(const_int 16 [0x10])) [178 this+0 S4 A16])
(nil)))
=> I'll add some code to drop the expr_list from all insns...
