[M68k] Building simple program using std::future results in internal compiler error #59161
Comments
EugeneZelenko
added
backend:m68k
crash
|
@llvm/issue-subscribers-backend-m68k |
|
My initial observation is that we have no support for |
|
I can only share that TLS support was lacking for a long time in glibc on m68k and was only added later when ColdFire was developed. I have asked your question on the m68k-specific Debian and Linux kernel mailing lists, there are definitely people who can answer your question(s). |
Appreciated ;) |
|
TLS support for m68k was introduced in gcc in gcc-mirror/gcc@75df395. Maybe this commit can help adding TLS support to LLVM for m68k? |
|
And we don't have TLS support in the backend yet (see: https://github.com/llvm/llvm-project/blob/main/llvm/lib/Target/M68k/M68kISelDAGToDAG.cpp#L423). So, I guess adding TLS support will be the next bigger goal for the backend. |
|
I appreciate that this horse has bolted, but I'd be interested in anyone's thoughts on the performance of the TLS m68k implementation. In general, you see at least a 50% hit, as documented here: https://news.ycombinator.com/item?id=30007986 And observed on my own 68030 based homebrew board. I'm compelled to run pre TLS (2008-ish) debian, with the latest HEAD kernel, because of the perf hit caused by TLS. The biggest frustration is it impacts non threaded applications (eg, /bin/uname) as well. It's jolly frustrating that this work towards a more complete 68k Linux userland is only really useful for virtualised "machines" (even then the perf hit is the same). Unfortunately I wasn't really following 68k developments back when these choices were made. Apologies for storming on about something not technically related. |
|
@aslak3 That's okay, I was wondering the same thing. I know there are no free registers, but I was naively wondering whether re-purposing one of them would be less of a performance hit, given that we are looking to break ABI anyway. I only have a vague understanding of assembly though, so I can't offer anything useful here. |
Well, without TLS, we simply won't be able to compile any modern code. So I don't think we really have a choice. If we're going to be stuck to old code, there is no point in investing into further development, is there?
Not really. There is faster hardware available these days such as the Apollo accelerators or the PiStorm. Yes, it gets slower on older 68k machines, but again, what's would be the point to put more effort into the effort when you can't modern code.
FWIW, we have a Discord for m68k where these issues can be discussed. |
Well, we broke the ABI on m68k anyway back when TLS support was added. And IIRC, one registers was sacrificed for that matter. |
My comment was WRT the implementation of TLS support in m68k Linux, not the obvious need for it. It's a syscall overhead for all userspace which is the cause of a significant perf hit, nothing more complex than that. I was wondering what alternative implementations there might have been when it was implemented back in 2008 or so and why they were discounted, etc.
I agree, but also that perf hit applies to all m68k systems equally. For instance, on my AMD64 desktop using the QEMU virt layer I see a 50% hit on disk perf via dd when TLS is in play. I personally find this to be pretty shocking and sad, but that's just my view. As I said, it applies to all software, multithreaded or not.
Yeap I'm on it. |
|
Seems that the performance issue is stem from the absence of a dedicated thread pointer register (so we are forced to use the |
|
Coming back to the original issue which is compiling the sample code in With the patches from: it's possible to successfully compile the code when passing diff --git a/llvm/lib/Target/M68k/M68kExpandPseudo.cpp b/llvm/lib/Target/M68k/M68kExpandPseudo.cpp
index 5383d3107955..8ecd5724354d 100644
--- a/llvm/lib/Target/M68k/M68kExpandPseudo.cpp
+++ b/llvm/lib/Target/M68k/M68kExpandPseudo.cpp
@@ -251,9 +251,9 @@ bool M68kExpandPseudo::ExpandMI(MachineBasicBlock &MBB,
MIB = BuildMI(MBB, MBBI, DL, TII->get(M68k::RTS));
} else if (isUInt<16>(StackAdj)) {
- if (STI->atLeastM68020()) {
- llvm_unreachable("RTD is not implemented");
- } else {
+ // if (STI->atLeastM68020()) {
+ // llvm_unreachable("RTD is not implemented");
+ // } else {
// Copy PC from stack to a free address(A0 or A1) register
// TODO check if pseudo expand uses free address register
BuildMI(MBB, MBBI, DL, TII->get(M68k::MOV32aj), M68k::A1)
@@ -269,7 +269,7 @@ bool M68kExpandPseudo::ExpandMI(MachineBasicBlock &MBB,
// RTS
BuildMI(MBB, MBBI, DL, TII->get(M68k::RTS));
- }
+ // }
} else {
// TODO: RTD can only handle immediates as big as 2**16-1.
// If we need to pop off bytes before the return address, weThus, in order to completely fix this issue, we will have to implement the RTD instruction in addition to adding TLS support. |
Glad to hear this ! Could you kindly open an issue for us ? Thanks :) |
Done: #60554 |
|
We should be able to close this. There is another minor issue in the backend with regards to TLS though. Going to open a new issue. |
|
Filed a new issue for the regression I found, see #63162. Closing this one. |
Trying to cross-compile the following sample program:
Trying to compile this code using the M68k backend results in an internal compiler error:
Attaching the preprocessed source plus run script in a zipped archive.
future-82834f.zip
CC @mshockwave @0x59616e
The text was updated successfully, but these errors were encountered: