-
Notifications
You must be signed in to change notification settings - Fork 22
insertIndirectBranch not implemented but SizeRelaxationPass uses it (LLVM-55) #8
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
Comments
Have you tried compiling LLVM with assertions enabled? I'm working on a compiler frontend and found many bugs that way - including things that looked like optimizer/backend bugs but were really frontend bugs. The fact that it's only an issue on Windows tells me it might be a memory corruption or similar in LLVM, which you can often catch with assertions. Also maybe check differences in LLVM build config. I've seen bugs only happening on Windows because I had disabled threading there but was still using it. |
Thanks for the hints. Actually with assertions enabled I get an assertion at https://github.com/espressif/llvm-xtensa/blob/757e18f722dbdcd98b8479e25041b1eee1128ce9/lib/CodeGen/MachineBasicBlock.cpp#L1360 I assumed it's normal for this work in progress backend currently but I'll compare the behavior on OSX. I tried to build LLVM more or less like the usual Rust build does: https://github.com/rust-lang/rust/blob/41501a6b03a8f10d8c29dfcb37dbd5ff84b33f34/src/bootstrap/native.rs#L179 But I'm still puzzled why it generates apparently correct code as soon as I comment out BranchRelaxation and why But to be honest I'm far from really understanding what is really happening there. But it's a good idea to compare whats happening on Windows vs other platforms. |
That might just be a bug in the Xtensa backend - apparently someone somewhere is not updating liveness information? |
Hi @bjoernQ ! Thank you for information!. Can you attach the code which causes an error to reproduce situation? For example like there https://github.com/espressif/llvm-xtensa/issues/4#issuecomment-481116928 |
Hello @andreisfr ! Here are some LLVM BC files which should cause the error lib.zip Just trying to use I built LLVM with cmake configured like this and it then gets built using Visual Studio 2017 tools on my system In my case with BranchRelaxation it crashes - when I comment out the BranchRelaxation pass it works fine for me. |
Thank you, @bjoernQ ! I will investigate the problem |
Hi @bjoernQ ! Please, check https://github.com/espressif/llvm-project/tree/xtensa_release_9.0.1 version, I suppose this version fixes problem. |
I will give it a try and soon as possible. Thanks for the update |
Works fine for me! Thanks! |
This patch re-introduces the fix in the commit llvm@66b0cebf7f736 by @yrnkrn > In DwarfEHPrepare, after all passes are run, RewindFunction may be a dangling > > pointer to a dead function. To make sure it's valid, doFinalization nullptrs > RewindFunction just like the constructor and so it will be found on next run. > > llvm-svn: 217737 It seems that the fix was not migrated to `DwarfEHPrepareLegacyPass`. This patch also updates `llvm/test/CodeGen/X86/dwarf-eh-prepare.ll` to include `-run-twice` to exercise the cleanup. Without this patch `llvm-lit -v llvm/test/CodeGen/X86/dwarf-eh-prepare.ll` fails with ``` -- Testing: 1 tests, 1 workers -- FAIL: LLVM :: CodeGen/X86/dwarf-eh-prepare.ll (1 of 1) ******************** TEST 'LLVM :: CodeGen/X86/dwarf-eh-prepare.ll' FAILED ******************** Script: -- : 'RUN: at line 1'; /home/arakaki/build/llvm-project/main/bin/opt -mtriple=x86_64-linux-gnu -dwarfehprepare -simplifycfg-require-and-preserve-domtree=1 -run-twice < /home/arakaki/repos/watch/llvm-project/llvm/test/CodeGen/X86/dwarf-eh-prepare.ll -S | /home/arakaki/build/llvm-project/main/bin/FileCheck /home/arakaki/repos/watch/llvm-project/llvm/test/CodeGen/X86/dwarf-eh-prepare.ll -- Exit Code: 2 Command Output (stderr): -- Referencing function in another module! call void @_Unwind_Resume(i8* %ehptr) #1 ; ModuleID = '<stdin>' void (i8*)* @_Unwind_Resume ; ModuleID = '<stdin>' in function simple_cleanup_catch LLVM ERROR: Broken function found, compilation aborted! PLEASE submit a bug report to https://bugs.llvm.org/ and include the crash backtrace. Stack dump: 0. Program arguments: /home/arakaki/build/llvm-project/main/bin/opt -mtriple=x86_64-linux-gnu -dwarfehprepare -simplifycfg-require-and-preserve-domtree=1 -run-twice -S 1. Running pass 'Function Pass Manager' on module '<stdin>'. 2. Running pass 'Module Verifier' on function '@simple_cleanup_catch' #0 0x000056121b570a2c llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) /home/arakaki/repos/watch/llvm-project/llvm/lib/Support/Unix/Signals.inc:569:0 #1 0x000056121b56eb64 llvm::sys::RunSignalHandlers() /home/arakaki/repos/watch/llvm-project/llvm/lib/Support/Signals.cpp:97:0 #2 0x000056121b56f28e SignalHandler(int) /home/arakaki/repos/watch/llvm-project/llvm/lib/Support/Unix/Signals.inc:397:0 #3 0x00007fc7e9b22980 __restore_rt (/lib/x86_64-linux-gnu/libpthread.so.0+0x12980) #4 0x00007fc7e87d3fb7 raise /build/glibc-S7xCS9/glibc-2.27/signal/../sysdeps/unix/sysv/linux/raise.c:51:0 #5 0x00007fc7e87d5921 abort /build/glibc-S7xCS9/glibc-2.27/stdlib/abort.c:81:0 #6 0x000056121b4e1386 llvm::raw_svector_ostream::raw_svector_ostream(llvm::SmallVectorImpl<char>&) /home/arakaki/repos/watch/llvm-project/llvm/include/llvm/Support/raw_ostream.h:674:0 #7 0x000056121b4e1386 llvm::report_fatal_error(llvm::Twine const&, bool) /home/arakaki/repos/watch/llvm-project/llvm/lib/Support/ErrorHandling.cpp:114:0 #8 0x000056121b4e1528 (/home/arakaki/build/llvm-project/main/bin/opt+0x29e3528) #9 0x000056121adfd03f llvm::raw_ostream::operator<<(llvm::StringRef) /home/arakaki/repos/watch/llvm-project/llvm/include/llvm/Support/raw_ostream.h:218:0 FileCheck error: '<stdin>' is empty. FileCheck command line: /home/arakaki/build/llvm-project/main/bin/FileCheck /home/arakaki/repos/watch/llvm-project/llvm/test/CodeGen/X86/dwarf-eh-prepare.ll -- ******************** ******************** Failed Tests (1): LLVM :: CodeGen/X86/dwarf-eh-prepare.ll Testing Time: 0.22s Failed: 1 ``` Reviewed By: loladiro Differential Revision: https://reviews.llvm.org/D110979 (cherry picked from commit e8806d7)
I'm using a Rust port (https://github.com/MabezDev/rust-xtensa) that uses this LLVM backend. It works on my OSX system but not on my Windows system - but it used to work on Windows using some quite early commits of this LLVM backend. For me actually it crashes during compilation on Windows.
I investigated a bit and was able to track it down to
insertIndirectBranch
isn't implementedThen I realized that
insertIndirectBranch
is called via BranchRelaxation which is enabled by https://github.com/espressif/llvm-xtensa/blob/757e18f722dbdcd98b8479e25041b1eee1128ce9/lib/Target/Xtensa/XtensaTargetMachine.cpp#L137Probably it used to work for me before since previously XtensaTargetMachine configured the passes like this
So it wasn't using BranchRelaxation before.
I don't understand why it's working on OSX and apparently Linux and it's only me who runs into this problem (and only on Windows) - however given the code it shouldn't be platform dependent.
I guess implementing
insertIndirectBranch
would be a good solution.Locally I just commented out
addPass(&BranchRelaxationPassID);
fromXtensaPassConfig::addPreEmitPass()
and I'm now able to compile and run code.Unfortunately implementing a proper solution (i.e.
insertIndirectBranch
) myself is way over my head.The text was updated successfully, but these errors were encountered: