[PATCH] D66822: Hardware cache line size builtins

zoecarver added a comment. In D66822#1656476 , @jfb wrote: > 1. Add to target infrastructure Refs D74918 . Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D66822/new/

[PATCH] D66822: Hardware cache line size builtins

jfb requested changes to this revision. jfb added a comment. This revision now requires changes to proceed. Sorry for the delayed response, I was on vacation. Thanks for tackling it! I don't think this is the approach I would take. From my dev meeting lightning talk I would instead: 1. Add to

[PATCH] D66822: Hardware cache line size builtins

zoecarver added a comment. > BTW, I note that facebook uses 128 bytes for x86 They also use 64 for arm which is interesting (the opposite of this patch). Also, see this comment in the same snippet: > We assume a cache line size of 64, so we use a cache line pair size of 128 Which would

[PATCH] D66822: Hardware cache line size builtins

zoecarver added a comment. We should probably tell people never to use this, period. That being said, I like your idea of having it be a constant. The only issue would be when, in the next few years, people start shipping CPUs with 256-byte-wide cache lines. Repository: rG LLVM Github

[PATCH] D66822: Hardware cache line size builtins

jyknight added a comment. numbers for cacheline size. In D66822#1647664 , @zoecarver wrote: > > Passing-by remark: i'm not sure it is possible to **guarantee** that this > > will be always correct and that no ABI break will happen. > > You're right. I

[PATCH] D66822: Hardware cache line size builtins

zoecarver added a comment. It may be a good idea only to enable this when `-march=native`. And _maybe_ remove the constexpr requirement (though it would make this feature significantly less useful it would also make it significantly more accurate). Repository: rG LLVM Github Monorepo

[PATCH] D66822: Hardware cache line size builtins

zoecarver added a comment. > Passing-by remark: i'm not sure it is possible to **guarantee** that this > will be always correct and that no ABI break will happen. You're right. I should have said, "least-likely to cause an ABI break." And I completely agree that there is **no way** to

[PATCH] D66822: Hardware cache line size builtins

lebedev.ri added a comment. > My implementation switches on the target triple to get the max cache line > size for that target. I am not sure if this is the best way to implement > these builtins, but it will ensure that there is not an ABI break. Passing-by remark: i'm not sure it is possible

[PATCH] D66822: Hardware cache line size builtins

zoecarver created this revision. Herald added a reviewer: jfb. Herald added subscribers: cfe-commits, kbarton, aheejin, javed.absar, nemanjai. Herald added a project: clang. Creates the `__builtin_hardware_destructive_interference_size` and `__builtin_hardware_constructive_interference_size`