[Moving discussion to LLVMdev]
@llvm.dbg.stoppoint actually does read and write memory, in a
sense. It's a point where a user could stop in a debugger, and
use the debugger to both read and write memory. If the optimizers
are allowed to reorder or delete memory operations, these
intrinsics will become inconsistent with the actual program.
If it's desirable to do optimizations and there are debug
intrinsics preventing that, it would be preferable to modify or
eliminate the debug intrinsics to get them out of the way,
rather than leave them in place and letting them become
inconsistent with the actual program state. This way, a debugger
could correctly tell the user "this is optimized code, I don't
know what's going on", which is fine, rather than presenting
bogus information, which is something we'd like to avoid. I
know several other people are thinking about how to do this;
it might be a good thing to bring up on llvmdev.
Indeed, there are optimizations that would invalidate debug info, but
there are really simple optimizations that could preserve debug info.
I am actually more interested in Analysis working in presence of debug
info, but in order to get any meaningful results, you need to run some
transformations, at least GVN, otherwise loops aren't transformed to
canonical form either.
So we could:
- teach GVN that a dependency on a debug instruction is not a real one,
and should ignore it
- teach GVN to remove stale dbg info due to its transformations
- if we cannot preserve dbg.stoppoint we may try to preserve
region.begin() and region.end() [or convert stoppoints to regions]
Consider you are debugging a crash in optimized code:
Hey, your program crashed somewhere in function foo in foo.o
Hey, your program crashed in function foo in region foo1.c:100 - foo1.c:120
Also preserving debug info about variable names can be useful.
For llvm.readcyclecounter, I think it's fine to inhibit
optimizations. It's hard to understand what it means if it
doesn't :-). Do you have an example where being able to
do optimizations would be useful?
I don't have a real example for the readcycles, but I could think that a
profiler wants to profile something, and inserts it and it ends up with:
Now, the presence of read_cycle_counter would prevent GVN from working
in that loop, since read_cycle_counter would be seen as a depedency of
every load and store (including the one from the induction variable). So
by inserting the read_cycle_counter it pessimized the code, and getting