[llvm-commits] [llvm] r86748 - in /llvm/trunk: include/llvm/Analysis/ include/llvm/CodeGen/ include/llvm/Transforms/Utils/ lib/Analysis/ lib/CodeGen/AsmPrinter/ lib/CodeGen/SelectionDAG/ lib/Transforms/Utils/

[Nick Lewycky]

Devang Patel wrote:
>
>>>> Thanks.  Is there a test for this ordering stability?
>>>
>>> You mean test to reason why we use list instead of map because of ordering requirement ?
>>
>> I'm not exactly sure how to parse that question, so sorry if this
>> isn't an appropriate answer, but I mean something under either test/
>> or unittests/ that would fail if anyone removed the list or used the
>> map where they should have used the list. For example, it could llc a
>> file with several scopes and CHECK that the DW_whatevers appeared in a
>> particular order. That would overspecify the requirement, I think, and
>> so would need to be updated any time the logic changed, but it would
>> fail if the output order depended on anything but the input.
>
> No there is no such test. Such test would check retrieving objects from a pointers' map is not deterministic.

No, you've mentally placed the test at the wrong level. Obviously map 
iteration isn't deterministic while list iteration is, but what a test 
would test for is a change in behaviour of your map/list-using code.

Did the non-determinstic behaviour of map cause any bugs in debug 
emission? If so then that's what you would test for. The test should be 
something that uses the debug emission and passes when you use list but 
fails if you were to roll back to using a map.

On the other hand, if this is just a precautionary change to remove any 
chance of non-determinism, and you don't know that it made any 
externally-visible difference then I should think it'd be fine to pass 
on writing a test for that!

Nick

  And there are tons of places where llvm code base is careful, by using 
appropriate data structure,  to not introduce nondeterministic behavior. 
llvm-gcc bootstrap is very sensitive about such things and every one 
dreads bootstrap failures due to miscompare!
>
> -
> Devang
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
>