Do not instrument pointers with address space attributes since we cannot track them anyway. Instrumenting them results in false positives in ASan and a compiler crash in TSan. (The compiler should not crash in any case, but that's a different problem.)
Details
Diff Detail
Event Timeline
LGTM with two nits.
| lib/Transforms/Instrumentation/AddressSanitizer.cpp | ||
|---|---|---|
| 953 | Are we sure the cast is *always* valid? Maybe a dyn_cast + if would be better, but it’s up to you. | |
| test/Instrumentation/ThreadSanitizer/tsan_address_space_attr.ll | ||
| 32 | Can we check for the presence of the instrumentation call instead? The presence or non-presence of “addrspacecast” is a secondary thing. | |
| test/Instrumentation/ThreadSanitizer/tsan_address_space_attr.ll | ||
|---|---|---|
| 32 | (or CHECK-NOT for both if the previous code inserted an invalid addrspacecast) | |
| lib/Transforms/Instrumentation/AddressSanitizer.cpp | ||
|---|---|---|
| 953 | I'll double check again, but I think we do always get PointerType here. | |
| test/Instrumentation/ThreadSanitizer/tsan_address_space_attr.ll | ||
| 32 | Can you clarify what you want to test for? Codegen crashes on the addrspacecast instruction. I can also test that the load is not instrumented with an additional check. | |
| test/Instrumentation/ThreadSanitizer/tsan_address_space_attr.ll | ||
|---|---|---|
| 32 |
Yes please, that’s exactly what I meant. | |
Are we sure the cast is *always* valid? Maybe a dyn_cast + if would be better, but it’s up to you.