Fri, May 24
May 15 2019
May 7 2019
May 6 2019
May 3 2019
May 2 2019
Apr 30 2019
Apr 29 2019
Thanks @richard.townsend.arm . I have updated the patch.
Apr 26 2019
Apr 25 2019
Apr 24 2019
Apr 23 2019
Apr 22 2019
Do you need to modify AArch64TargetLowering::isEligibleForTailCallOptimization to prevent a tail call in cases where the tail call would return the wrong value?
Apr 19 2019
Thanks @kristof.beyls for the review. We are still working on the combining the clang patches which should fix PR41135 and PR41136. I will then add unit tests to this patch.
Apr 12 2019
The document you linked in the LLVM change (https://docs.microsoft.com/en-us/cpp/build/arm64-windows-abi-conventions?view=vs-2019#return-values) says that small POD types are returned directly in X0 or X0 and X1, but this looks like it will always return them indirectly. I think we also need to check the size of the type, and fall back the the plain C ABI for small types.
Apr 11 2019
Apr 10 2019
The new patch now also handles struct returns for instance methods.
Apr 5 2019
Got rid of the confusing SuppressSRet logic. The "inreg" attribute is now used to indicate sret returns in X0.
Refer https://bugs.llvm.org/show_bug.cgi?id=41135 for a detailed discussion on the issue. Please review this and the related clang patch and let me know if this implementation is something we can proceed with.
Mar 22 2019
Although, as you rightly pointed out that ordered sets of pointers are as non-deterministic as unordered ones.
What if you store pointers to the elements of an array? In that case, it should be deterministic.----------- |1|2|3|5|6| ----------- ^ ^ p q
In the above example, pointer p's memory address will always be less then q's, so in an ordered set, iterating over them would be deterministic. When hashing algorithms come into the picture, than it wouldn't be :^)
Mar 21 2019
Following are the assumptions/limitations of this patch:1. The assumption is that iteration of ordered containers of pointers is not non-deterministic.
Could you please explain which type of non-determinism we are addressing here? If our issue is that iteration order is not consistent across runs, then an unordered set of integers seems just as non-deterministic as an unordered set of pointers. On the other hand, if our issue is that pointer values vary between runs, then an ordered set of pointers seems just as non-deterministic as an unordered set of pointers. Are unordered sets of pointers distinguished because they lie in the intersection of these categories and thus avoid the most false positive cases? If so, for someone debugging non-deterministic behavior in their code, would it be useful to add a strict option that shows other cases too? If not, maybe we could document our reasons somewhere.
Mar 20 2019
Ping for reviews please.
Mar 14 2019
I was trying to write another checker for hashing of pointers. Basically, I wanted to match all instances where the keys of std::map are pointers. Writing an AST matcher for std::map is straightforward. However, I am not sure how to check for pointer keys after matching std::map.
Mar 13 2019
Could you please add a commit that changes the top of the file on your previous commit? Feel free to do that without review (I can't commit it myself atm).
Also, what is the difference between these two: https://clang.llvm.org/docs/analyzer/checkers.html, https://clang-analyzer.llvm.org/available_checks.html. It seems they document similar stuff. Should we add the doc for each new checker in both of these?
The obvious question, why not implement this in clang-tidy?
Mar 12 2019
Following are the assumptions/limitations of this patch:
Mar 8 2019
Mar 6 2019
Mar 4 2019
@NoQ Ping 2 for reviews please.
Mar 1 2019
Feb 28 2019
How about we keep the discussion on the original patch (D57986)? I think we explored the problem space a fair bit there & I'll advocate for the same thing here as I did there: Sorting before emission is likely more efficient than keeping a continuously sorted container, if there's a separate "build" and "iterate" phase you can sort between. At least that's my understanding. std::map and MapVector would both grow memory usage, probably not prohibitively, but a fair bit.
Especially if these are just small clusters of collisions - they can be put in a small container, sorted, emitted, then thrown away - better than changing the whole long-lived/larger data structure.
Sorry, I just saw this now. I had a patch to fix this issue (but I didn't get time to follow-up on it). See D57986.
Feb 26 2019
Feb 25 2019
But, as a work-in-progress alpha checker, the direction is set and looks great. Please let @NoQ have the final say.