[llvm-commits] PATCH: Fix non-deterministic debug info output for C++ inputs

Bendersky, Eli eli.bendersky at intel.com
Wed May 2 22:10:33 PDT 2012


I looked at the FoldingSetVector implementation and LGTM with tiny nits:

1.       Typo s/interator/iterator/

2.       Is there any special reason to put “SelfT tmp = *this; ++*this; return tmp;” all on the same line?
Eli



From: llvm-commits-bounces at cs.uiuc.edu [mailto:llvm-commits-bounces at cs.uiuc.edu] On Behalf Of Chandler Carruth
Sent: Thursday, May 03, 2012 07:44
To: <llvm-commits at cs.uiuc.edu>; llvm cfe; Eric Christopher
Subject: [llvm-commits] PATCH: Fix non-deterministic debug info output for C++ inputs

Hello folks,

We found a pretty gross bug. Turns out debug information for template methods of template classes can, in some specific circumstances, end up with non-deterministic output. The cause is the fact that the specializations for a function template are stored in a FoldingSet which has non-deterministic iteration order. At one point, the debug info generation needs to emit information for all function template specializations, and walks this to do so.

There are a few possible solutions to this:

1) Sort the specializations by their mangled name. This is really only a partial solution as it doesn't fix cases where there *is* no accurate family name: consider if the class template is function local, etc. Also, it leaves a land-mine waiting for the next person to iterate over this particular interface in the AST.

2) We could add a sequence number to each specialization and then copy all of them to a vector, sorting before we walk the list of them. This is somewhat tempting, and appears to be used in at least one other place, but it makes iteration extremely expensive, and again, penalizes every future user of the AST's API.

3) The solution I settled on was to build a data structure that better suits this use case. The desired iteration order is the insertion order, which SetVector models cleanly, but we don't have a FoldingSetVector. That said, it is very easy to add. =] I've done so, and used it to fix the issue. See the two attached patches, one which introduces this ADT, and the other uses it in Clang.


I've included a contrived test case that exercise the non-determinism. It also appears to be a fantastic test case at exercising other parts of LLVM/Clang, as plugging in large numbers and running the optimizer is... very very slow. =]
---------------------------------------------------------------------
Intel Israel (74) Limited

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20120503/f7bab627/attachment.html>


More information about the llvm-commits mailing list