https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58315
--- Comment #21 from Aldy Hernandez <aldyh at redhat dot com> ---
On 02/24/2015 12:39 AM, rguenther at suse dot de wrote:
> But yes, we have multiple such assignments to 'this' at the (possible
> assembler) location of a single statement which of course doesn't help.
>
> Thus we should DCE the debug stmt sequences between real stmts like
>
>> D.166591 ={v} {CLOBBER};
>> # DEBUG this => &D.166589
>> # DEBUG D#20 => &D.166589.D.71066
>> # DEBUG this => D#20
>> # DEBUG D#19 => &D#20->D.67748
>> # DEBUG this => D#19
>> _1479 = &MEM[(struct Row *)&D.166589].D.66121;
>
> to the following at least ("DSE" actually, based on the actual
> name of the LHS a debugger might use to refer to the variable)
Let me see if I understood this correctly. We need a DSE/DCE pass right
before var-tracking that would eliminate the redundant `this' statements
right before a non debug statement. So, for something like this:
# DEBUG this => &cs
# DEBUG D#61 => &cs.D.73561
# DEBUG this => D#61
# DEBUG topol => 0
# DEBUG D#60 => &D#61->D.71953
# DEBUG this => D#60
# DEBUG D#59 => &D#60->rows
# DEBUG this => D#59
# DEBUG D#58 => &D#59->D.66859
# DEBUG this => D#58
# DEBUG D#57 => &D#58->_M_impl
# DEBUG this => D#57
# DEBUG this => D#57
# DEBUG this => D#57
MEM[(struct _Vector_impl *)&cs]._M_start = 0B;
<other non DEBUG stmts>
<bb 8>:
# DEBUG this => &D.166575
# DEBUG D#21 => &D.166575.D.73843
# DEBUG this => D#21
# DEBUG D#19 => &D#21->D.67748
# DEBUG this => D#19
_1448 = &MEM[(struct Row *)&D.166575].D.66121;
Parma_Polyhedra_Library::Row_Impl_Handler::~Row_Impl_Handler (_1448);
...we would delete all the "DEBUG this" in the first batch with the
exception of the last one (DEBUG this => D#57). All the intervening
"DEBUG D#[0-9][0-9]" statements would remain. For the second batch, we
would also delete all the "DEBUG this" statements except the last one
(DEBUG this => D#19)?
Is this what you have in mind?
>
>> D.166591 ={v} {CLOBBER};
>> # DEBUG D#20 => &D.166589.D.71066
>> # DEBUG D#19 => &D#20->D.67748
>> # DEBUG this => D#19
>> _1479 = &MEM[(struct Row *)&D.166589].D.66121;
>
> As to "between stmts" that is because after each 'stepi' in the
> debugger you reach a new state computed by var-tracking. Intermediate
> state-transitions are not interesting as long as you preserve the
> "last" state before the next instruction.
>
> Thus in reality you'd want to perform this DCE/DSE right before
> var-tracking (or during the var-tracking insn scan phase)
>
>> Also, it may not be the DEBUG statements at fault, but the inefficiency
>> of the testcase itself (creating all these objects), in which case,
>> perhaps we could notice this behavior at var-tracking time, and bail?
>> Though this sounds like a kludge.
>
> Of course the issue is very large and repetitive functions. Thus
> another idea is to simply split up such functions. If just by
> making var-tracking work on SESE (or SEME) regions and dealing
> with the boundaries conservatively.
>
> Eventually this can be "hacked" by fake splitting/restoring the
> CFG around vt_initialize/vt_find_locations/vt_finalize. Maybe
> easier than to make them work on a CFG region.
The DCE/DSE pass sounds more straightforward IMO, but I just don't want
to deal with data flow equations ;-).
