[PATCH] D62766: [Attributor] Deduce "nosync" function attribute.
JF Bastien via Phabricator via llvm-commits
llvm-commits at lists.llvm.org
Sat Jun 29 15:04:04 PDT 2019
jfb added a comment.
You should also add a test function with inline assembly.
================
Comment at: llvm/lib/Transforms/IPO/Attributor.cpp:315
+ AtomicOrdering Failure = cast<AtomicCmpXchgInst>(I)->getFailureOrdering();
+ // Only if both are relaxed, than it can be treated as relaxed.
+ // Otherwise it is non-relaxed.
----------------
"then"
================
Comment at: llvm/lib/Transforms/IPO/Attributor.cpp:378
+ /// We are looking for volatile instructions or Non-Relaxed atomics.
+ /// FIXME: We should ipmrove the handling of intrinsics.
+ for (Instruction *I : InfoCache.getReadOrWriteInstsForFunction(F)) {
----------------
"improve"
================
Comment at: llvm/test/Transforms/FunctionAttrs/nosync.ll:317
+ ret i32 4
+}
----------------
I don't think you can generally treat intrinsics as `nosync`. Unless you know they're actually `nosync` you should assume that intrinsics might synchronize.
For example:
```
int a;
void i_totally_sync() {
__builtin_ia32_clflush(&a);
}
```
Corresponds to:
```
tail call void @llvm.x86.sse2.clflush(i8* bitcast (i32* @a to i8*))
```
You should have a test for this, and it should definitely *not* be `nosync`.
The other option here is to go and add a field to all intrinsics, so when creating a new one we have to figure out whether it'll definitely sync, maybe sync, or never sync. I don't think that's in scope for this patch.
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D62766/new/
https://reviews.llvm.org/D62766
More information about the llvm-commits
mailing list