diff options
| author | Christian Krinitsin <mail@krinitsin.com> | 2025-07-17 09:10:43 +0200 |
|---|---|---|
| committer | Christian Krinitsin <mail@krinitsin.com> | 2025-07-17 09:10:43 +0200 |
| commit | f2ec263023649e596c5076df32c2d328bc9393d2 (patch) | |
| tree | 5dd86caab46e552bd2e62bf9c4fb1a7504a44db4 /results/scraper/fex/1729 | |
| parent | 63d2e9d409831aa8582787234cae4741847504b7 (diff) | |
| download | qemu-analysis-main.tar.gz qemu-analysis-main.zip | |
Diffstat (limited to 'results/scraper/fex/1729')
| -rw-r--r-- | results/scraper/fex/1729 | 16 |
1 files changed, 16 insertions, 0 deletions
diff --git a/results/scraper/fex/1729 b/results/scraper/fex/1729 new file mode 100644 index 000000000..3a48cf26f --- /dev/null +++ b/results/scraper/fex/1729 @@ -0,0 +1,16 @@ +Can we optimize non-locking RMW atomic operations? +Currently we convert all lock RMW ops to acquire-release semantics. + +Couple weird things to investigate here + +1. Basic ALU ops without lock + - Non-lock ops get turned in to load + ALU + store + - Can potentially convert in to atomic memory operation **without** acquire-release semantics. + - Should only generate on ARMv8.1+ if it supports atomic memory ops + - Might need hardware TSO support? + 2. RMW ops that don't imply LOCK but really should, used without LOCK + - **CMPXCHG, CMPXCHG8B, CMPXCHG16B, XADD** + - These instructions don't imply LOCK prefixes but they are almost universally used with them + - Linux kernel has some optimization where it backpatches `lock cmpxchg` in to `nop cmpxchg` on uniprocessors? Citation needed. + - These might be able to be converted to operations with...release? semantics? + - Needs investigation. |