Reload patch v5
Bernd Schmidt
crux@Pool.Informatik.RWTH-Aachen.DE
Thu Oct 1 06:07:00 GMT 1998
> 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
More information about the Gcc-patches
mailing list