Re: Reload patch v5

[Bernd Schmidt <crux at Pool dot Informatik dot RWTH-Aachen dot DE>]

> I'm still trying to wrap my head around why you have to delete them each time
> and what other side effects this may have.
> 
> For example, since space in the stack is allocated via assign_stack_local, aren't
> we going to bloat stack usage if we have lots of caller saves?  We may even
> get more reloads since some targets have limited displacement capabilities in
> reg+d addresses.

No, the modifications I made should have no effect on the code that allocates
stack slots for caller-saves.  caller-save keeps track (in regno_save_mem)
which slots it has already allocated, and re-uses old ones in every iteration.
My patch only makes reload delete the old caller-save insns (they may no
longer be necessary, e.g. if all pseudos have been spilled out of a
caller-saved reg), but the old stack slots are not forgotten.  (Even in the
old code, setup_save_areas is called in every iteration).

> One thought would be to never allow new caller saves to be created after the
> first pass through.  I think this would involve removing the call clobbered
> regs from consideration when we try to reallocate a spilled pseudo which crosses
> calls.
> 
> So on the first pass we find all the locations where we need to insert save and
> restore insns and insert them using the pseudo reg, then let reload operate
> normally.
> 
> Is there some reason that won't work?

It's less general than what's present in the last reload patch, and I don't
see why you'd want to restrict caller-saves in this way.

> Note that Joern added a couple new reload optimizers recently that'll need
> converting to using the new chains and the life info in them instead of
> used_spill_regs.  Interesting enough, using the new chains and their life info
> may actually make Joern's optimizers more effective :-)

I'll look into this.

> Given the size of the patch, the benchmarking needs, and the knowledge that
> Joern also has a mega patch to improve inheritance he's working on, I'm starting
> to think we should probably try to phase this in with multiple steps.
> 
> Any chance I could get you to extract out the scratch stuff and submit it
> separately?  Then once that's approved to do the same for the basic code to
> build & use the new chain structure?  Then as the last stage the changes which
> actually implement localized spilling?

That's possible, of course.  Suggested steps:

- remove scratch handling from local-alloc
- add build_insn_chain in global.c, and the corresponding code in stupid.c
- convert to do local spilling (disabling caller saves for that moment)
- convert caller-save to deal with the new situation.

Some of these might come your way today or tomorrow, as I have time.

Bernd