This is the mail archive of the
mailing list for the GCC project.
Re: VTA merge - introduction
On Jun 5, 2009, Richard Guenther <firstname.lastname@example.org> wrote:
> On Fri, Jun 5, 2009 at 9:34 PM, Alexandre Oliva<email@example.com> wrote:
>>>> available in what sense? ÂIf this kept the variable available as in it
>>>> got a stack slot, this would have been flagged by -fcompare-debug, so
>>>> you must be speaking of something else. ÂI can't tell what it is.
>>> Available in the sense that it is still in the IL and the variable lists
>>> and thus consumes memory and compile-time during stmt walks.
>> Erhm... ÂIf it's removed from the stmt list without vta, I think it
>> should be removed from it with vta as well, otherwise we'd risk getting
>> different code.
>> It should remain only in the lexical blocks, so that we can generate
>> debug info, and where it doesn't cost much, considering we don't walk it
>> often and we need to keep the decl around to generate debug info anyway.
>> Does this not match what you see?
> No, I see it used in DEBUG stmts.
> # DEBUG p <= &x;
But neither p's nor x's DECLs are available in the IL any more, right?
I understood, from what you wrote before, that they were.
A statement that p is modified at that point remains, for sure, as it
should. Even if we were to drop the &x, we'd still have to note that
whatever value p held before that point is no longer applicable.
So it's not like retaining the &x makes a lot of difference, and it
enables us to say that p points to that if we end up assigning a memory
location to x anyway.
Is your objection that there's a mark saying that p is modified, and
that this would slow down walking over statements around that point?
Alexandre Oliva, freedom fighter http://FSFLA.org/~lxoliva/
You must be the change you wish to see in the world. -- Gandhi
Be Free! -- http://FSFLA.org/ FSF Latin America board member
Free Software Evangelist Red Hat Brazil Compiler Engineer