This is the mail archive of the gcc@gcc.gnu.org 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] |
Mark Mitchell <mark@codesourcery.com> writes: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."
Why do you expect that? Independently of whether or not theirLet 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.
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.
I agree that if it does nottest for the optimization, then we should remove it.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.)
-- Mark Mitchell CodeSourcery, LLC (916) 791-8304 mark@codesourcery.com
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |