[clang] [clang][CodeGen] Emit atomic IR in place of optimized libcalls. (PR #73176)

James Y Knight via cfe-commits cfe-commits at lists.llvm.org
Tue Feb 13 10:46:00 PST 2024


jyknight wrote:

What config is this bot using? Is it "-target sparc-solaris -mcpu=v9" (that is: 32-bit sparc, but with v9 cpu available)?

I see that SparcV9TargetInfo sets MaxAtomicInlineWidth to 64 unconditionally. But, the message `warning: large atomic operation may incur significant performance penalty; the access size (8 bytes) exceeds the max lock-free size (4  bytes) [-Watomic-alignment]` indicates that MaxAtomicInlineWidth is 32. OK, wait, this class is poorly-named. SparcV8TargetInfo really means "sparc 32-bit" and SparcV9TargetInfo really means "sparc 64-bit". So: this is actually using SparcV8TargetInfo, instead. 

Yet, even then, SparcV8TargetInfo appears to [intend to configure](https://github.com/llvm/llvm-project/blob/16140ff219b68f61fedf92df13019d89a4990a47/clang/lib/Basic/Targets/Sparc.h#L168) MaxAtomicInlineWidth to 64 when using a V9 CPU. That doesn't seem to be actually happening, though.

OK, so the frontend is apparently buggily configured to only support 32-bit atomics in 32-bit mode, even when a V9 CPU is available.

That, then, was covering up a bug in the backend. The backend claims to (and should be able to!) support 64-bit atomics in 32-bit mode. But it doesn't actually, right now.

I'll send a patch to fix this by limiting atomics to 32-bit in the backend when `!Subtarget->is64Bit()`, which will get things back to working, though it doesn't address those deeper issues.

https://github.com/llvm/llvm-project/pull/73176


More information about the cfe-commits mailing list