This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [Bug target/30271] -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

There may be other places where these magical alias sets are applicable;
if anyone wants to suggest some, we will look into it.



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]