Repository navigation
[clang] _GCC_DESTRUCTIVE_SIZE potentially incorrect on Apple arm64 #182951
Description
On Apple arm64, sysctl -a | grep cacheline reports hw.cachelinesize: 128. However,
$ echo | clang++ -target apple-macos-arm64 -dM -E - | grep -E "__GCC.*SIZE"
#define __GCC_CONSTRUCTIVE_SIZE 64
#define __GCC_DESTRUCTIVE_SIZE 64
That is a bit surprising, since I would expect at least __GCC_DESTRUCTIVE_SIZE to be 128. Did I misunderstand something, is there a goal to be compatible with GCC, or is that really a bug?
@philnik777 or @huixie90 I think this came up in some of our prior discussions
CC @AaronBallman as the author of #89446, which added that macro to Clang.
Activity
llvmbot commentedon Feb 23, 2026
@llvm/issue-subscribers-clang-driver
Author: Louis Dionne (ldionne)
Details
On Apple arm64, `sysctl -a | grep cacheline` reports `hw.cachelinesize: 128`. However,That is a bit surprising, since I would expect at least
__GCC_DESTRUCTIVE_SIZEto be 128. Did I misunderstand something, is there a goal to be compatible with GCC, or is that really a bug?@philnik777 or @huixie90 I think this came up in some of our prior discussions
CC @AaronBallman as the author of #89446, which added that macro to Clang.
huixie90 commentedon Feb 24, 2026
I remember last time during live review we found out the number did not match the cacheline size but it was technically conforming . I don’t remember the number exactly but the destructive size is something like 256, which guarantees no false sharing, but it is bigger than the actual cacheline size
AaronBallman commentedon Feb 24, 2026
FWIW, when I added that macro, I tagged backend maintainers to try to get reasonable initial values, but not everyone weighed in. So I pulled values from GCC: #89446 (comment) which is how we ended up where we are today.
ldionne commentedon Feb 24, 2026
Yeah, I didn't intend to blame or anything, I even approved that PR. I was just curious to know whether there was a special rationale for the value we ended up with on arm64 / Apple.
Is it then correct to say that the current values were simply inherited from what GCC does?
Do we also agree that a better value for arm64 on Apple would then be:
It seems that
__GCC_DESTRUCTIVE_SIZEwas already updated to256on arm64 by bce2cc1 to correspond to what ARM documents, so I don't think that one needs to change.Also useful related SO question: https://stackoverflow.com/questions/79579748/is-stdhardware-destructive-interference-size-right-for-macs
Edit: Correction in my comment: bce2cc1 already updated destructive size, not constructive size.
AaronBallman commentedon Feb 24, 2026
Yeah, I think that's roughly correct though we have no requirement to match GCC or be stable between releases: https://releases.llvm.org/19.1.0/tools/clang/docs/ReleaseNotes.html#c-17-feature-support (we should probably document that along with all the other implementation defined stuff if we don't already).
ldionne commentedon Jul 6, 2026
Circling back to this, I had made one crucial mistake in my comments above. At the time of my comment, Apple Clang had not picked up bce2cc1 yet, but in reality upstream Clang was already reporting:
This is correct and conforming behavior. We could potentially report 128 instead, but that would make us different from GCC and there might be other considerations as well. Since I originally filed this because I thought destructive was
64and that was wrong, I'll close this as NTBF.ldionne commentedon Jul 9, 2026
Actually, revisiting this, I think we should go for a better definition of
__GCC_DESTRUCTIVE_SIZEon Apple arm64 -- we align stuff like the contention table inside libc++.dylib based on these numbers, and being 2x too large is just wasteful.(Sorry for the back-and-forth on this)
[clang] Use a 128-byte destructive interference size on Apple AArch64 (…
[clang] Use a 128-byte destructive interference size on Apple AArch64 (…