This is the mail archive of the gcc-patches@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]

Re: VTA merge - introduction


On Jun  5, 2009, Richard Guenther <richard.guenther@gmail.com> wrote:

>> are, it's different statements we're talking about, and there's this
>> thought of representing it so that you could step through side effects
>> that didn't generate code, in much the same way that GDB enables you
>> today to step into or out of an inlined function without changing the
>> PC.

> Uh.  And this is useful for what?  Yes, that is a serious question.

To get closer to -O0 debugging.

Consider that you're stepping through optimized code on IA64.

There's a sequence of computations and assignments.

Because of the nature of IA64, a lot of stuff is computed in parallel.

However, the effects are to become visible piecemeal.

So you attach the changes in the user's view of the program state to the
binding points, rather than to the computations moved up, and then, you
single step through the changes in the view, that say stuff like âoh,
variable x is now at r67 rather than r35â or so.

We don't really have means to represent this in debug info (location
lists list PC ranges, so if PC doesn't change, the view can't change),
but maybe we'll be able to get to that some day.

>> 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?

> Note that this is for non-registers in this case, so we do not even print
> <value optimized out> during debugging.

It is surely discarded at a later point, so that we don't generate any
debug info whatsoever.  Since this variable is not a gimple register,
VTA won't have (isn't supposed to, anyway) have any effect on debug info
pertaining to it.

-- 
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


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