[PATCH] D69247: [AArch64][Builtins] Avoid unnecssary cache cleaning

Kyrill Tkachov via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Fri Oct 25 09:57:34 PDT 2019


ktkachov added a comment.

In D69247#1719597 <https://reviews.llvm.org/D69247#1719597>, @peter.smith wrote:

> I'm on vacation at the moment, will take a look next week as this will need some checking of the architecture manual. This LKML message https://lkml.org/lkml/2018/10/9/698 implies that in some cases it is insufficient to just read CTR_EL0.{IDC,DIC}, as a 0 also requires a check with CTR_EL1 which can't be done in userspace. Would you be able to take a look at that thread? For compiler-rt we need something that works on all CPUs at EL0.


The way I read that LKML discussion is that it's a kernel discussion on how to expose this feature to userspace (EL0). On earlier architecture revisions this field is architected as "reserved zero", meaning reads from it will be 0. Therefore at boot time the kernel needs to look at a higher EL to figure out if the feature actually exists. Once it figures that out it will set the EL0 field (probably through trapping) to the appropriate value for userspace, which is what we should be reading. Note that a value of 0 here is conservatively correct: it means userspace has to do the explicit cache clean operation, which is always safe to do in this context. This change tries to figure when it's safe to avoid that cache clean.

This logic is the same as the libgcc logic in http://gcc.gnu.org/r276122 so it looks good to me. The libgcc implementation caches the value of ctr_el0 in a static variable to avoid a sysreg read on every call. Can this be done here as well?


Repository:
  rCRT Compiler Runtime

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D69247/new/

https://reviews.llvm.org/D69247





More information about the llvm-commits mailing list