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>