------- Comment #7 from zadeck at naturalbridge dot com 2007-10-30 00:38 ------- Subject: Re: -mstrict-align can an extra for struct agrument passing
zadeck at naturalbridge dot com wrote: > ------- Comment #6 from zadeck at naturalbridge dot com 2007-10-29 14:09 > ------- > These stores to the stack are not really anything that dse can handle. It is > good at removing stores addressed off the frame pointer that go dead when the > function returns, but it must be more conservative with stack pointer based > addresses. > > This is a result of the fact that gcc does not allow the program to play as > many games with values accessed off of the frame as it does with values > accessed off of the stack. In fact, i think it would be wrong for dse to > remove these stores because (i believe) that the caller is allowed to see > values accessed off the stack pointer when the function returns. > > On the other hand, if i am wrong about this, it would not be hard to teach dse > to do some of the same tricks to stack based addresses as it currently does > for > frame based addresses but i think that i pressed iant pretty hard on this > stuff > when i was writing this pass and this was all he would allow me to do. > > I think that if this bug is going to be "cleared", the right way to go is do > better analysis about generating those stores in the first place. > > > ian t and i discussed this earlier tonight. ian does not believe that the solution that we will pursue for this bug merits inclusion into stage 3 so i am writing here so we can come back for it when stage 1 opens. one of the features that is encoded into the current implementation of dse is the ability to apply very aggressive treatment to addresses that have been given their own magical alias sets. We use these magical alias sets in the current dse to mark the stack locations that reload uses during spilling as being known never to be aliased. This allows us to bypass the currently conservative aliasing code and treat these locations as if they have completely transparent semantics, which in fact they do. our plan is to mark the locations referenced off of virtual registers as having these magical alias sets iff there is no place in the code that takes the address of one of these locations. A quick scan at the start of pass_instantiate_virtual_regs should be able to identify the places where the address are taken. This should allow us to clear any dead when the function returns or globally redundant stores of the variables addressed off these virtual registers. There may be other places where these magical alias sets are applicable; if anyone wants to suggest some, we will look into it. Comments? kenny -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30271
