-
Notifications
You must be signed in to change notification settings - Fork 14
The order of assembly code output from attached IL is broken when optimisation is O1 or greater #83
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
Update: I realised the FileCheck directives in the LLVM were both too specific in some places (specifying some instructions at the start that aren't pertinent to this test case) and not general enough. In essence the test is about whether the optimiser breaks the while loop. You should see:
Using variables, I improved the test:
This breaks at the moment and should start working when the optimiser bug is fixed. I attempted bugpoint using these scripts... test-compile.sh
bugpoint.sh
Using This produces a bunch of files. Normally I'd expect bugpoint-reduced-simplified.bc to have the simplified test case. Sadly it looks a bit thin...
Or compiled:
Which is not exhibiting the behaviour so bugpoint has been too aggressive and has removed the code that triggered the optimiser bug. All the other .bc files, when compiled are still not showing the buggy behaviour. So unless anyone has a better idea, I think we cannot easily get a reduced test case and we'll have to debug with the full sized LLVM IR file here. |
OK so more details, I tried using opt-bisect-limit to find the faulting step. Even with it set to 0 (which should be no optimise passes), it produces mis-ordered code. I debugged that with print-after-all to see what was happening. The clue is somewhere in these 7000 lines. Any help gratefully received!... |
By accident I forgot to specify arch = avr this time and got an interesting result...
Compare that to avr...
you can see that the order of instructions looks sane on the other architecture (arm?) but is broken on AVR. So it's definitely something about our transformations that's breaking it. |
It's definitely a reordering thing that is being introduced just with assembly printed for this backend. Look at this investigation...
The first ("GOOD") is the output from another architecture for exactly the same input LLVM IR, the second ("BAD") is the output from avr for this LLVM IR. The third ("REPAIRED") is my suggestion for how to fix this in this one example. It looks like the order of machine basic blocks has gone wrong. If you move the MBBs represented by the code between labels LBB0_5: and LBB0_7: up before the comment ; BB#3: (presumably the start of the fourth machine basic block) then it all works and it then exactly mirrors the structure of the arm(?) code from the "GOOD" compile. |
As a further note, I looked at the source LLVM IR...
... this straighforwardly rearranges to...
...which gives some clues as to what might have gone wrong as it mirrors the wrong assembly. |
Apple looked at it. Their simple solution was to run the llvm ir through opt first. It worked! |
Working from this minimal example, I've worked out Swift code that ends up broken when compiled into AVR assembly, if and only if O1 or greater.
This produces the following LLVM IR when run through the swiftc in Xcode 8.3.3 (swiftc version Apple Swift version 3.1 (swiftlang-802.0.53 clang-802.0.42)).
(Note I've amended this LLVM IR with comments and with test labels so it makes a valid test in llvm-lit if placed in test/CodeGen/AVR.)
When compiled with -O=0, this produces very cumbersome but valid assembly:
When compiled with -O=1 we get this assembly, which is much more efficient but doesn't work. In particular the while (true) {} loop is effectively broken.
The rjmp jump back to LBB0_1 should (probably?) be the last instruction. Instead there's another couple of labels after that. Looks like some reordering went wrong during optimisation?
I want to use this script with bugpoint to reduce the test case but I'm new to this so it will take a while to get my head round the tool.
The text was updated successfully, but these errors were encountered: