xuruobin via llvm-dev
2018-Aug-13 12:43 UTC
[llvm-dev] Assembly mimatch between windows and linux llvm.(probably caused by sort algorithm)
To whom it may concern, I'm running some testcases(A and B) in Linux LLVM(built in Ubuntu16.04) and Windows LLVM(built by Visual Studio 2015), both of which were LLVM 4.0.0 and built with same source codes, but I got different assembly files(A_Linux != A_Windows, B_Linux = B_Windows). Privacy reasons prevent me from sharing my testcases here, sorry. I compared debug information and found the root cause in MachinePipliner.cpp that Node orders differed after sort algorithm. There were two `std::sort` in this file and when I replaced them with 'std::stable_sort', these two assembly files became the same but other assembly files differed(A_Linux = A_Windows, B_Linux != B_Windows). I cannot figure out the reason and could you give me some advice why this happened and what sort algorithm should I use to get exactly same assembly files? Best regards, Ruobin -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180813/debbfa15/attachment.html>
Martin J. O'Riordan via llvm-dev
2018-Aug-14 12:11 UTC
[llvm-dev] Assembly mimatch between windows and linux llvm.(probably caused by sort algorithm)
Hi Ruobin, I have had similar problems in the past, and it is generally caused by the hash value being used to determine relative ordering between two (or more) values which are otherwise considered equal. Since the implementation of the hashing is different between VC++ and the one in 'libstdc++' or LibC++, this can result in apparently non-deterministic ordering. In my case the problem occurred when sorting BBs during scheduling, but it is likely that you are seeing something similar. I don't remember the exact details, but I think I resolved it by using the BB# when my ordering test indicated that the values were equal. If it is any consolation, this does not generally result in "wrong" code, just "different" code. MartinO From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] On Behalf Of xuruobin via llvm-dev Sent: 13 August 2018 13:44 To: llvm-dev at lists.llvm.org Cc: Yuchao (Michael) <michael.yuchao at huawei.com> Subject: [llvm-dev] Assembly mimatch between windows and linux llvm.(probably caused by sort algorithm) To whom it may concern, I'm running some testcases(A and B) in Linux LLVM(built in Ubuntu16.04) and Windows LLVM(built by Visual Studio 2015), both of which were LLVM 4.0.0 and built with same source codes, but I got different assembly files(A_Linux !A_Windows, B_Linux = B_Windows). Privacy reasons prevent me from sharing my testcases here, sorry. I compared debug information and found the root cause in MachinePipliner.cpp that Node orders differed after sort algorithm. There were two `std::sort` in this file and when I replaced them with 'std::stable_sort', these two assembly files became the same but other assembly files differed(A_Linux = A_Windows, B_Linux != B_Windows). I cannot figure out the reason and could you give me some advice why this happened and what sort algorithm should I use to get exactly same assembly files? Best regards, Ruobin -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180814/3444caa8/attachment.html>
xuruobin via llvm-dev
2018-Aug-15 10:31 UTC
[llvm-dev] 答复: Assembly mimatch between windows and linux llvm.(probably caused by sort algorithm)
Hi MartinO, Thanks for your answer, but I still cannot figure out why std::stable_sort generated two different result. As far as I know, the order of equivalent elements is guaranteed to be preserved by std::stable_sort regardless of VC++ and libstdc++. Ruobin. 发件人: Martin J. O'Riordan [mailto:MartinO at theheart.ie] 发送时间: 2018年8月14日 20:12 收件人: xuruobin <xuruobin at huawei.com>; 'LLVM Developers' <llvm-dev at lists.llvm.org> 抄送: Yuchao (Michael) <michael.yuchao at huawei.com> 主题: RE: [llvm-dev] Assembly mimatch between windows and linux llvm.(probably caused by sort algorithm) Hi Ruobin, I have had similar problems in the past, and it is generally caused by the hash value being used to determine relative ordering between two (or more) values which are otherwise considered equal. Since the implementation of the hashing is different between VC++ and the one in ‘libstdc++’ or LibC++, this can result in apparently non-deterministic ordering. In my case the problem occurred when sorting BBs during scheduling, but it is likely that you are seeing something similar. I don’t remember the exact details, but I think I resolved it by using the BB# when my ordering test indicated that the values were equal. If it is any consolation, this does not generally result in “wrong” code, just “different” code. MartinO From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] On Behalf Of xuruobin via llvm-dev Sent: 13 August 2018 13:44 To: llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org> Cc: Yuchao (Michael) <michael.yuchao at huawei.com<mailto:michael.yuchao at huawei.com>> Subject: [llvm-dev] Assembly mimatch between windows and linux llvm.(probably caused by sort algorithm) To whom it may concern, I’m running some testcases(A and B) in Linux LLVM(built in Ubuntu16.04) and Windows LLVM(built by Visual Studio 2015), both of which were LLVM 4.0.0 and built with same source codes, but I got different assembly files(A_Linux != A_Windows, B_Linux = B_Windows). Privacy reasons prevent me from sharing my testcases here, sorry. I compared debug information and found the root cause in MachinePipliner.cpp that Node orders differed after sort algorithm. There were two `std::sort` in this file and when I replaced them with ‘std::stable_sort’, these two assembly files became the same but other assembly files differed(A_Linux = A_Windows, B_Linux != B_Windows). I cannot figure out the reason and could you give me some advice why this happened and what sort algorithm should I use to get exactly same assembly files? Best regards, Ruobin -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180815/52fffb45/attachment.html>