AW: new ira optimization - adding a loop to ira

[stefan@franke.ms]

> -----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