Negative numbers reported with: opt -time-passes -track-memory

[Quuxplusone]

Bugzilla Link	PR34535
Status	NEW
Importance	P normal
Reported by	Anmol P. Paralkar (anmparal@cisco.com)
Reported on	2017-09-08 16:42:33 -0700
Last modified on	2017-09-08 17:43:47 -0700
Version	trunk
Hardware	PC All
CC	anmparal@cisco.com, ditaliano@apple.com, llvm-bugs@lists.llvm.org, matze@braunis.de
Fixed by commit(s)
Attachments	p0.bc (1988 bytes, application/octet-stream)
Blocks
Blocked by
See also

Why are there negative numbers in the Mem column?

opt -time-passes -track-memory ./p0.bc -O3 -o p0.O3.bc

===-------------------------------------------------------------------------===
                      ... Pass execution timing report ...
===-------------------------------------------------------------------------===

…

---User Time---   --User+System--   ---Wall Time---  ---Mem---  --- Name ---
0.0010 ( 33.3%)   0.0010 ( 33.3%)   0.0012 ( 41.2%)     324576  Simplify the CFG
…
 0.0000 (  0.0%)   0.0000 (  0.0%)   0.0000 (  0.4%)      -7184  Scalar Evolution Analysis
…

Ref: http://lists.llvm.org/pipermail/llvm-dev/2017-September/117069.html

[Quuxplusone]

Please provide a bitcode file to reproduce this.

[Quuxplusone]

Attached p0.bc (1988 bytes, application/octet-stream): Bitcode file to reproduce the problem.

[Quuxplusone]

When a pass removes more datastructures (instructions, metadata, ...) than it creates I can see this happening. The number is the difference of memory used before and after running a pass.

[Quuxplusone]

(In reply to Matthias Braun from comment #3)
> When a pass removes more datastructures (instructions, metadata, ...) than
> it creates I can see this happening. The number is the difference of memory
> used before and after running a pass.

Yes, that's what happening (just debugged).
I think it's a little weird but presumably we should live with it?
The alternative would be that of just report zero in ca se the number is
negative? (I guess that may be less confusing, but also less useful).

[Quuxplusone]

I'd leave the behavior as is.

(If anything I would remove the whole option, and recomment people to rather use something like valgrind/massif, instruments etc. to capture actual peak memory usage. I don't see the use in before/after pass comparisons, esp. with analysis passes sometimes staying alive for a longer timer).

[Quuxplusone]

(In reply to Matthias Braun from comment #5)
> I'd leave the behavior as is.
>
> (If anything I would remove the whole option, and recomment people to rather
> use something like valgrind/massif, instruments etc. to capture actual peak
> memory usage. I don't see the use in before/after pass comparisons, esp.
> with analysis passes sometimes staying alive for a longer timer).

Yes, I tend to agree.
FWIW, the same issue happens with `-time-passes`, LVI returns pretty much no
time but Jump Threading and VRP account for all the time spent in it, so the
numbers are already somehow wrong.
I'd claim that with the approximate measurements time-passes is still useful no
matter what although, as you say, it's hard to imagine why you don't want to
use valgrind (or something similar) for memory measurements.

[Quuxplusone]

(In reply to Matthias Braun from comment #3)
> When a pass removes more datastructures (instructions, metadata, ...) than
> it creates I can see this happening. The number is the difference of memory
> used before and after running a pass.

Then, I'd say that keeping the negative numbers is actually a good thing
because it helps in understanding pass behaviour. If the documentation:

-track-memory                                                  - Enable -time-
passes memory tracking (this may be slow)

is updated to reflect the same; it would not be confusing anymore.