Support for LLVM 8/9 (LLVM-51) #5
Comments
|
I think it's working. At first I got a crash ("Guru Meditation Error") but it's gone now, the example code is working. |
|
Hi @sapir , thank you for sharing results of your work. We also ported Xtensa backend to LLVM 8 release and shared patches for upstream. We will soon upload new improvements in current Xtensa backend to github and also we have plans to migrate on LLVM 8/9 release in our repository. |
|
LLVM 9 was just announced. Is the new goal to target LLVM 10? https://lists.llvm.org/pipermail/llvm-announce/2019-September/000085.html |
|
Any updates on this? |
|
Hi, The Xtensa backend is ported now release 9.0 of the llvm-project, now it is under verification, this version will be uploaded soon. |
|
Great! @andreisfr any idea on how/when to continue upstreaming this work? While it's great that the Espressif fork of LLVM is available and at a recent version, it would be far more usable if it was upstream. As a compiler maintainer (for TinyGo), using a fork is impractical as it means depending on speedy updates from Espressif. If we had used your LLVM 7 fork, that would mean we would still have incomplete support for RISC-V and WebAssembly today - which are upstream. Honestly I think it's best to ping llvm-dev more, especially with the patch series you have published so people have something to look and comment at. Having some sort of green light from LLVM maintainers also helps give some confidence that it's fine to merge these patches. I would gladly help review patches myself, but I feel too inexperienced with the LLVM backend to give good reviews unfortunately. |
|
Hi @sapir , @beriberikix , @jeandudey , @aykevl ! Now current version of the LLVM Xtensa backend is based on release 9.0.1 (default branch in https://github.com/espressif/llvm-project). |
github-actions
bot
changed the title
|
@andreisfr sounds like this issue can be closed then? |
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'd like to use this with the current Rust compiler, but Rust currently depends on LLVM 8 or 9.
I got this fork compiling with LLVM 8 here:
https://github.com/sapir/llvm-project/tree/llvm-8-xtensa
I think it works, as I managed to use it to compile an example Rust project as described here, although I haven't actually run the resulting binary on an ESP32 yet.
The text was updated successfully, but these errors were encountered: