Hi, On Tue, 29 May 2012, Richard Guenther wrote:
> > The other change in function.c further improves the temp slot > > machinery. While expanding free_temp_slots is called after each > > statement, and if it is able to free a slot it needs to update the > > RTX->slot mapping (a htab_t). The freeing of slots was done > > incorrectly, it overwrote the slot in question with NULL, but it > > should have used htab_clear_slot. > > That looks like a bugfix applicable to branches? Perhaps, though the results of this bug are only worse code generation. When the chains are broken due to the bug some RTX->slot mappings aren't found anymore, but the code deals conservatively with that. > > A variant of this regstrapped on x86_64-linux, all > > languages+Ada+objc++, but after some changes I'm redoing that > > regstrap. Okay for trunk if that passes? > > The volatile handling is very odd - the objects_must_conflict_p code > basically says that two volatile vars may always share stack slots?! That's correct. Basically everything can share a stack slot that conflicts already for other reasons than address-based considerations. Two volatile accesses always conflict and hence they'll never be swapped (which is what creates the problems with stack slot sharing). > What's the reasoning for this, or handling volatiles special in any way? > I'd rather remove this fishy code (and if at all, ensure that volatile > automatics are never coalesced with any other stack slot). Volatility is no reason for not sharing stack slots, it's not fishy code. Ciao, Michael.
