https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58315
Aldy Hernandez <aldyh at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |jason at gcc dot gnu.org,
| |rguenth at gcc dot gnu.org
--- Comment #16 from Aldy Hernandez <aldyh at gcc dot gnu.org> ---
Among other things (because I'm not 100% sure this is the only thing wrong
here) we seem to be generating and awful lot of GIMPLE_DEBUG statements, even
for intermediate values we will throw away.
I am not sure whether this is just a very inefficient testcase, a byproduct of
the way we expand expressions, or the myriad of DEBUG statements we create.
For instance, in a snippet of the testcase:
Variable A(0);
Variable B(1);
Variable C(2);
Variable D(3);
Constraint_System cs;
cs.insert(Coefficient("2251799813685248")*A
>= Coefficient("-5895288448651847"));
cs.insert(Coefficient("5895288437392848")*A
+ Coefficient("3643488632714799")*B
- Coefficient("2251799813685248")*C
>= Coefficient("-19077554137963492"));
...
...we create a temporary instance for each Coefficient constructor call, as
well as a temporary instance for the result of the '*' and '>=' operators, and
a temporary instance for the conversion of [ABC] to a Linear_Expression.
Basically, we create temporary instances of every class we create along the way
(expected), but unfortunately we then create DEBUG statements for each
destructor call in each temporary variable that was created, particularly for
the `this' pointer which is quite useless for debugging IMO.
For instance, the result of the ">=" operator gets stored in D.166575, but as
you can see below, there are quite a few DEBUG statements for this temporary
which will never see the light of (debugging) day:
D.166575 = Parma_Polyhedra_Library::operator>= (&D.166573, &D.166574);
<bb 7>:
Parma_Polyhedra_Library::Constraint_System::insert (&cs, &D.166575);
<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);
If you look at the "einline" tree dump, you can see numerous DEBUG statements
for each destructor call:
MEM[(struct &)&D.166591] ={v} {CLOBBER};
# DEBUG <L0> => NULL
MEM[(struct &)&D.166591] ={v} {CLOBBER};
# DEBUG <L0> => NULL
MEM[(struct &)&D.166591] ={v} {CLOBBER};
# DEBUG <L0> => NULL
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;
Parma_Polyhedra_Library::Row_Impl_Handler::~Row_Impl_Handler (_1479);
ad nauseum.
These DEBUG statements eventually end up as a multitude of VAR_LOCATION rtl
notes that take an awful lot of memory to process. As I've said, I'm not 100%
this is the problem, but I'm quite suspect.
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.
