On Fri, Mar 6, 2015 at 7:04 PM, Alexandre Oliva <aol...@redhat.com> wrote: > On Feb 26, 2015, Alexandre Oliva <aol...@redhat.com> wrote: > >> So far, all the differences I looked at were caused by padding at the >> end of BBs, and by jump stmts without line numbers at the end of BBs, >> both right after the debug reset stmts the proposed patch introduces. > > Further investigation showed there were other sources of spurious > differences: > > - copies arising from the expansion of PHI nodes; source code > information associated with these copies points at the source of the > copy, which is hardly useful and sensible.
Care to explain? We spend quite some resources to maintain them (locations on PHI args, that is). Btw, I'd expect tree-ssa-copyrename.c to be a source of bogus base variables still. Richard. > - "optimization" of single-range location lists to a location expression > covering the entire function, which extends, often incorrectly, the > range of the expression, and thus the coverage of the function. > > By patching GCC so as to eliminate these differences (patches attached > for reference), I managed to reduce the coverage differences in > libgcc_s.so to a manageable size (about a dozen variables in 3 functions > in 2 object files), so I could manually investigate each one of them. > > All remaining differences amounted to single insns, originally before > the reset debug stmt introduced by the patch, computing subexpressions > of expressions expanded after the return point of the inlined function. > Because of TER, this often causes stmts to be moved past corresponding > debug stmts. This is a long-standing and long-known issue to me, thus > nothing particularly new brought about or worsened by the proposed > patch, and that would be fixed with stmt frontiers. > > Ultimately, the issue is not so much that the insn gets emitted at a > different spot, but rather the possibility that no insn will remain at > the point where it was expected, which might make it impossible (with > current compiler and debugger) to inspect the results of that > computation. The worst the reset debug stmts introduced by this patch > could do is to make those effects not visible at other points of the > computation, where they are not guaranteed or expected to be visible to > begin with. > > That said, it might be nice if we emitted partial of full expansions of > subexpressions at their original location, relative to debug stmts > expanded to debug insns, rather than all at the point of the full > expression. I recall having started something along these lines years > ago, but that project never got to a working state. > > > The differences in libstdc++.so, even after the patches intended to > minimize differences, are too many to investigate in depth, but from > what I can tell from a quick glance at the diff in dwlocstat > per-variable per-range coverage dumps, nearly all of the differences > amount to one insn in the final range, which likely means TER-introduced > differences. > > > > > -- > 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 Brasil GNU Toolchain Engineer >
