On Apr 4, 2019, Richard Biener <rguent...@suse.de> wrote: >> If there's any instruction or view that would be reached by the earlier >> bind (the one that precedes the one we'd drop or reset), it would get >> wrong debug information if we were to drop the bind rather than reset >> it. If there isn't, whatever happens to the bind will have no effect. >> This suggests to me that resetting it is the right thing to do.
> Hmm. I was thinking of > # i_1 = PHI <0(2), i_4(4)> > # DEBUG i => NULL > # DEBUG i => i_1 > # DEBUG BEGIN_STMT > that might be OK(?) and in gdb I can't find it doing any harm. What > I suggested was to, for example, notice that there's a PHI defining > 'i' in the destination and thus it would be safe to drop the debug-bind *nod*. It could be done. I just meant a reset would also do. > (it's now associated with a "wrong" stmt/view since we dropped the > DEBUG BEGIN_STMT as well?). The view it would be associated with is the subsequent one, at the BEGIN_STMT marker, and it's overridden before that, so it doesn't matter. That's why removing or resetting has the same effect in the end. >> Now, if we were to try to duplicate the logic that decides whether the >> bind might possibly be observable, in order to drop it on the floor >> instead of resetting it, we should look for another bind of the same >> variable before any real stmt or debug marker. If we find one, it would >> be ok to drop the bind instead of resetting it. I suppose we might even >> make this part of the debug bind resetting logic, or introduce separate >> but reusable functionality for this sort of cleanup. > Hmm, but with the BEGIN_STMT markers still in place the views would > make the different values observable, no? Not if there's another overriding bind before them, no. >> /me mumbles something about PHI debug binds ;-) > Eh. But yes, sth like > # DEBUG PHI i => <NULL(2), i(5)> > meaning to reset on the edge into the loop and keep it "as is" > on the other edge would be equivalent to having the debug reset > on the edge. That would of course just delay the issue to RTL > expansion where PHIs get replaced by copies (and that has to be > compare-debug safe). OTOH in (non-CFG-layout-mode?) RTL we can > have insns between basic blocks (aka on edges). Yeah, I've started (thought-)exploring these possibilities years ago, but didn't get very far. > I'll see to add a guality testcase for my simple loop example above > (and try to trick it into going wrong with the patch some more) and > then apply the patch tomorrow. Thanks! -- Alexandre Oliva, freedom fighter https://FSFLA.org/blogs/lxo Be the change, be Free! FSF Latin America board member GNU Toolchain Engineer Free Software Evangelist Hay que enGNUrecerse, pero sin perder la terGNUra jamás-GNUChe
