The situation around -mabi for AArch64 is a bit awkward: Clang uses it to select the ARM64 calling convention (-mabi=aapcs vs -mabi=darwinpcs) while GCC uses it to select between LP64 and ILP32. I'm not sure how we should be handling this.

I fully agree that this likely wasn't intentional, but this is still very useful for code that can't use FP registers for whatever reason (e.g. kernels). Regarding the ABI, it doesn't need to be officially defined: it just needs to be compatible with other code compiled with -mgeneral-regs-only.

Currently using Clang with -mgeneral-regs-only generates perfectly fine soft-float AArch64, with the except of the va_arg() implementation which is fixed here. In fact Rust even has a aarch64-unknown-none-softfloat which relies on this behavior in LLVM. I believe this behavior is *more* useful than GCC's which simply rejects float/double types, and it makes sense to keep it and fix it.

Note that the case in PR57988 doesn't involve any out-of-range shifts in the source program. The current codegen means that with (1i128 << 0) you end up calling __ashldi with a shift amount of -64. If that's something we're happy with then the documentation should be fixed and I can go update Rust's compiler-builtins to wrap instead of panicking on out-of-range shifts in debug builds (which is how this bug was discovered).

Updated test.

For context, I encountered a linker error caused by this in Rust which does use the IR mangler.

Fixed to use dyn_cast_or_null.

Ping.

Ping.

LGTM

LGTM

LGTM

Don't merge thread-local constants

I'm not even sure what it would *mean* to have an unnamed TLS constant: I would expect an earlier pass to convert it to a normal constant rather than having to it in ConstantMerge.

Ping

Ping.

Merge thread_locals only if they use the same TLS mode

It's a bit more tricky than that:

• I'm not sure how we should handle the case where we are trying to merge 2 thread_local constants with different TLS models.
• In general we are better off *not* merging global constants with TLS constants since calculating a TLS address can be expensive.

The new operand to InlineAsm needs to be handled in llvm/lib/Transforms/Utils/ValueMapper.cpp otherwise you will end up with a bug similar to https://bugs.llvm.org/show_bug.cgi?id=45291.

Ping

In D94143#2500843, @kristof.beyls wrote:

My understanding is that AArch64 gnu_ilp32 support is present in mainline gcc, but not in mainline glibc nor in the mainline linux kernel. My understanding is also that it's unlikely that AArch64 gnu_ilp32 support will be added to mainline glibc or linux kernel anytime soon.
That makes me wonder how useful it is to support AArch64 gnu_ilp32 in mainline LLVM. It seems unlikely that it can be used for linux targets anytime soon. Are there non-linux targets using AArch64 gnu_ilp32?

Undo some unnecessary formatting changes.

In D94143#2493974, @joelkevinjones wrote:

In D16213 I introduced the MCTargetOptions argument to the MCAsmBackend constructor, as well as in constructor wrapper functions. This change touched multiple (every, probably) backend. Given the extension to embed the ABI in the Triple, can the MCTargetOptions argument be removed? That shouldn't be in this commit, I think.

clang-format & clang-tidy fixes

Ping. Please commit this for me since I don't have commit access.

I've added the Extra_IsConvergent flag which was also missing from FastISel.

By the way, I don't have commit access. Could you please commit this for me?

Sorry I don't understand, what do you want me to do?

Ping.

I don't have commit access, could you please commit this for me?

I'm not exactly sure. The original Rust bug report is pretty hard to extract since it seems to heavily depend on how rustc is splitting code into codegen units.

GCC's implementation is in libgcc/unwind-dw2.c. The relevant code is here. The PC is tracked separately in the ra field, while the registers are in the reg array.

Ping

I don't have commit access, could you commit this for me?

clang-format

They are not mentioned in the GCC documentation, but are documented in this comment in the GCC code:

The RISC-V unwinding spec is pretty bare: https://github.com/riscv/riscv-elf-psabi-doc/blob/master/riscv-elf.md#dwarf

Added context

Please commit on my behalf.

@mstorsjo Yes, I need someone to commit this for me.

Added a test.