-
-
Notifications
You must be signed in to change notification settings - Fork 5.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
replace mfence with lock'ed inst on x86 #48123
Conversation
This seems to be fine, linux changed to this a little while ago https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=450cbdd0125cfa5d7bbf9e2a6b6961cc48d29730 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Though as the kernel people, I'm not sure why the compiler doesn't just do this and I agree with @gbaraldi that it makes sense to align with the Linux-kernel instructions.
Looks like LLVM has support to emit this since https://reviews.llvm.org/D58632 and even emits it in the fallback case when the processor has no mfence. I don't know why it still emits mfence for the llvm |
@d-netto want to submit an upstream PR to remove the mfence case to see what they think? |
I believe @vchuravy already submitted a patch to LLVM to replace the |
Ah indeed: https://reviews.llvm.org/D129947 |
I may possibly say we should rather just wait for that to catch up with gcc and https://reviews.llvm.org/D129947, than worry about maintaining this if something changes again |
It will take a long time for the compilers to catch up. It landed in GCC12 and it will be a second before we get it into Clang. |
A dummy instruction with
lock
prefix should provide the same sequential consistency guarantees as anmfence
onx86
.This had a large performance impact when benchmarking work-stealing queues for parallel marking and it would be interesting to see how/if it affects performance in general.
CC: @vchuravy