AW: new ira optimization - adding a loop to ira

[<stefan at franke dot ms>]

> -----Ursprüngliche Nachricht-----
> Von: stefan@franke.ms <stefan@franke.ms>
> Gesendet: Freitag, 13. September 2019 12:45
> An: 'Richard Sandiford' <richard.sandiford@arm.com>
> Cc: gcc-help@gcc.gnu.org
> Betreff: AW: new ira optimization - adding a loop to ira
> 
> > -----Ursprüngliche Nachricht-----
> > Von: Richard Sandiford <richard.sandiford@arm.com>
> > Gesendet: Freitag, 13. September 2019 12:16
> > An: stefan@franke.ms
> > Cc: gcc-help@gcc.gnu.org
> > Betreff: Re: new ira optimization - adding a loop to ira
> >
> > <stefan@franke.ms> 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...