<table border="1" cellspacing="0" cellpadding="8">
<tr>
<th>Issue</th>
<td>
<a href=https://github.com/llvm/llvm-project/issues/70791>70791</a>
</td>
</tr>
<tr>
<th>Summary</th>
<td>
[aarch64][compiler-rt] clear_cache may cause problems with big.LITTLE architectures
</td>
</tr>
<tr>
<th>Labels</th>
<td>
new issue
</td>
</tr>
<tr>
<th>Assignees</th>
<td>
</td>
</tr>
<tr>
<th>Reporter</th>
<td>
jvstech
</td>
</tr>
</table>
<pre>
The [`clear_cache`](https://github.com/llvm/llvm-project/blob/0f99bc2d685c572c3b38fd0e1ca56be12d7e2f6a/compiler-rt/lib/builtins/clear_cache.c#L61) function implementation (used as the basis for `__builtin__clear_cache`) for aarch64 declares a variable to hold the `CTR_EL0` bit flags with [static lifetime](https://github.com/llvm/llvm-project/blob/0f99bc2d685c572c3b38fd0e1ca56be12d7e2f6a/compiler-rt/lib/builtins/clear_cache.c#L128):
```cxx
// Get Cache Type Info.
static uint64_t ctr_el0 = 0;
if (ctr_el0 == 0)
__asm __volatile("mrs %0, ctr_el0" : "=r"(ctr_el0));
```
Given that big.LITTLE chips tend to have different cache-line sizes, the use of `static` might be set from the larger and used on the smaller (or perhaps vice-versa) resulting in incorrect cleaning/invalidation information. I haven't been able to test it, so this is purely speculation at this point. I am open to and requesting feedback regarding this.
Incidentally, while I agree with the intent of [the original patch that made this change](https://github.com/llvm/llvm-project/commit/35cb3ee4ca477095bb3dd74f60ab932e185be63f), I believe libgcc has [the same potential bug](https://gcc.gnu.org/git?p=gcc.git;a=blob;f=libgcc/config/aarch64/sync-cache.c;h=ea3da4be02b37bc60aaf6d22319ff84fa8e84fc5;hb=ea3da4be02b37bc60aaf6d22319ff84fa8e84fc5#l36).
While it may be less performant, I believe reading the status each time is safer:
```cxx
// Get Cache Type Info.
uint64_t ctr_el0 = 0;
__asm __volatile("mrs %0, ctr_el0" : "=r"(ctr_el0));
```
(If any performance benefit _could_ be made from this change, it's that doing this avoids an extra conditional branch for validating the static lifetime.)
Any thoughts or feedback?
</pre>
<img width="1px" height="1px" alt="" src="http://email.email.llvm.org/o/eJzMVkGP27wR_TX0ZbCGRFqSdfAhXsfBAnsqFujRGFJDiSlFqiTlxP31BaV11gkKpOmh-ABDssjh6M2bNzPCGE3viA6sOrLqtME5DT4cvl5jIjVspO9uh7eBIG_XhbKE4aJQDcTqglUnxvdDSlNk4hPjZ8bPvUnDLLfKj4yfrb3eb09T8F9JJcbP0nrJ-LnQbSsV7-p9paqGKyHFXncFlQqrWlLJu4a4rpHxs_LjZCyFp5DPW5OPy9nYZFzM2x-otopx8VqXjLegZ6eS8Q7MOFkaySVcHhnfz5E6wAhpIJAYTQTtA7C6uFze_V4uv8SaHfoAiEEN9Q46UhYDRUC4YjAoLUHyMHjbLV5ZXTy__e3y-bVgdQHSJNAW-wjfTBoymTGDUWCNpmRG-stSWfI9423GVJxYcb_WxfpT37-vK7BChi-U4DmfhrfbRPDitN--W8B7yLNxqd5dEqgULmQLYOIEBRPHu53ROUUPu6sBb-8GAJcLxhEul6u3mIwlllHyMURgvCoYf747Z5wDExkeZ-IU8u2H6-wxh3b8JajHSL-YKzlIAyaQpt--vry9vX4GNZgpQiLXLTnHK0FntKZALsFC3pM1jiCaf1HMaLIi5kjgdRbGSkTWxWj6IYEkiJRABz8ulhZDTwHQdbAI1btlOY5oLYVMjg8wURhwinA1ip6uFCJmiQaKc85lD8aBccqHQCpBTqszrmf8bNwVrenWUjBO-zAu_7fwskTiGG8yJHJwF3WimMCkHEj0kAYTwUSY5kD2BnEiNdvVHaZ1d_LGpewQR_BTJtAv0QT650xxgaeJOonqHxCox9DlpXx0-0j-i1Omy2Vr7S2__NtgLGWvfSBaKynzYlzKvGduq2Ne8MH0xqGFCZMa1uyN2NEKTg3o-v-14JQfx8zEWVRKCqKdwl3TFG0lpei6ZqfrAmUrOJX7SlIt9CKyZ3gBSdbQlcAa2SsFA8Y73IgjweRzEAYtyLn_j-CU2vZu3vrQr1CZOE9MnJb1_HREJk5LQxBHzcRpfdGC2WmTD733LsbP8ebU073KxXFg4kQoOtxJKrgUjVR1gajrjnNRtlrvdxr3tN9pVWVz-Sf2XFhRM97-lNq_L6k0OS-3rH9LMWZJL3J06WfKAuG7QGhpInMEwpxYM1JWYkRN4fct6r_pUb9tTv-3zsP4_kUDutsHLYpAkiNtElyUn213ydQtyn7vHR_y5s9LxTZxlX_n7xUGePWmi4AO6HsKCMq7zuTyzdoL6NSwDLp7l3jg_WFebX-04_X6yd0gDX7uhxTBhx_lzcR50x1E14oWN3Qo63bfVLuyaDbDoRTVXrZKC912mppqXwpVlZXWZVPrYtdszIEXXJSFKEte7Hmz3emSY1tryaXaKVmzXUEjGrvNVZorY2NinOnQFE1bbixKsnH5sOHc0TdYNnMiqtMmHJbKlnMf2a6wJqb44SWZZJcvonvFVCdWHR9HZ3WCh1G5qFhh7vBT8NLS-D7oH2ZG9mQSqTQHips52MMfN58Ff57SS3z_DgAA__9-VhWi">