g++.old-deja/g++.mike/p7325.C - suspected bogus test case

[Mark Mitchell]

Zack Weinberg wrote:

>Mark Mitchell <mark@codesourcery.com> writes:
>
>  
>
>>>Let me reiterate that: it does not test anything meaningful.  It
>>>currently passes or fails depending on details of the platform ABI.
>>>Worse, the compiler is within its rights to extend the lifetimes of
>>>the temporaries because it notices that their addresses have been
>>>taken.  In fact, I expect Ken Zadeck's better alias analysis will
>>>have that effect.
>>>
>>>      
>>>
>>Why do you expect that?  Independently of whether or not their
>>addresses have been taken, the language says these temporaries go away
>>at a particular point.  If the compiler extends their lifetimes
>>unnecessarily because it thinks that pointers to them might survive,
>>that's an unnecessary pessimization -- unless it has some other good
>>reason for doing that.
>>    
>>
>
>It seemed a plausible consequence of the interprocedural escape
>analysis that he was describing.  Sure, the language says these
>temporaries go away at a particular point, but the data-flow analysis
>says their addresses are preserved, so the conservative optimization
>decision is not to recycle the storage.  We might choose to do it
>anyway, of course ... which I think only supports my point that this
>isn't an effective test for stack slot reuse.
>  
>
The point I was trying to make is that the alias analysis code should be 
taught about object lifetimes, if it has the behavior you describe.  In 
other words, if we already did the optimization the test is (trying to) 
test for, then introducing the optimization behavior you describe would 
be a regression.  I think my reaction to your insight is "we should make 
sure the optimizer guys know about this issue so they get this right" 
rather than "we should expect this test to fail when the optimizer gets 
smarter."

>>I agree that this an ugly mechanism for testing for this optimization,
>>and that some kind of stack-frame dumping might be better.  On the
>>other hand, we don't have a way of doing that at present.   And this
>>test does test for an optimization that we want to do, in general.
>>    
>>
>
>I don't see it as an effective test for that optimization.  At all.
>(I do agree that this is an optimization we want to do and currently
>don't.)
>
I agree that if it does nottest for the optimization, then we should 
remove it.

The code in "f" is checking that the return value from "foo" uses the 
same address both times.  The code in "g" is checking that the two 
temporaries constructed by calling "A()" have the same address both 
times.  Since nothing else is going on in those functions, that seems 
like a good thing to hope for; if it's not true, the stack frame is 
probably bigger than we want it to be.

I can certainly think of situations where the compiler could fail this 
test with optimization enabled even though it generally implemented the 
optimization.  For example, it might use two different slots for the 
temporaries; perhaps it can interleave instructions from one constructor 
with another without fear of aliasing, that way.  And, without 
optimization turned on, the compiler might not, well, optimize, 
therefore putting the temporaries in different spots just because that 
was simpler in some way.

So, I agree -- the compiler could reasonably fail this test either with 
optimization enabled or disabled, on plausible architectures.  
Therefore, it's OK to remove this test for 3.4.1 and on the mainline.

(By the way, given this analysis, your stack-frame dumping switch 
wouldn't help; the problem is that we don't really have a good method 
for saying when the compiler must reuse stack slots and when it must 
not.  Probably best to measure the total stack usage of some 
representative program(s) -- of which this might be one.)

-- 
Mark Mitchell
CodeSourcery, LLC
(916) 791-8304
mark@codesourcery.com