The optimization introduced in D83271 will verify a safety and a
precautionary condition. Until we find a proper solution for the former
we allow users to disable the check. If they do it and violate the
problematic (but probably unlikely) case, they will see UB, most likely
a crash when a non-function pointer is called. The flag has the word
unsafe in the name and the remarks are adjusted to provide some
insight what is happening.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
I think there's an unfortunate interaction with link time optimisation here. If there are external regions, but their code is combined with llvm-link before codegen, then a user could reasonably assume this flag is safe.
Would it would be correct to compile the individual source assuming there may be external uses, then llvm-link the source, then run the pass assuming there are no external uses? That's of interest to the amdgcn case as we can (currently) assume the whole program is available towards the end of the compilation.
If you set this flag and reach a parallel region from a target region outside the translation unit, you will experience problems as calling a non-function pointer is likely not to work. If you don't do this, you are all good.
Would it would be correct to compile the individual source assuming there may be external uses, then llvm-link the source, then run the pass assuming there are no external uses? That's of interest to the amdgcn case as we can (currently) assume the whole program is available towards the end of the compilation.
If you run O2 after linking *and* properly set the linkage of all your non-kernel functions to internal at that point, you don't need the flag. All the safe cases will then be handled automatically, all the unsafe ones rejected. At least that is what I suspect will happen.
I think this is good. It's dangerous, but it's also undocumented and has unsafe in the name.
I should be able to use this to sidestep limitations in the amdgpu function pointer implementation.