RFA: Speedup expand_used_vars by 30 times (PR38474)

[Michael Matz]

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.