This is an archive of the discontinued LLVM Phabricator instance.

SimplifyCFG: SinkThenElseCode shouldn't sink convergent functions
AbandonedPublic

Authored by tstellar on Mar 13 2017, 4:42 PM.

Details

Reviewers
jlebar
arsenm

Event Timeline

tstellar created this revision.Mar 13 2017, 4:42 PM
arsenm edited edge metadata.Mar 13 2017, 4:45 PM

I think this is a legal transformation. For example if you have a barrier like this with a divergent condition, the source program is broken. You can infer from this that %cond is a uniform condition

jlebar edited edge metadata.Mar 13 2017, 6:02 PM

I think this is a legal transformation. For example if you have a barrier like this with a divergent condition, the source program is broken. You can infer from this that %cond is a uniform condition

I don't think it's correct to infer that if you call a convergent function from within a branch that the branch is uniform. For one thing, the function may not actually call a barrier function -- "convergent" is a *restriction* on the optimizer, but it's not a promise to the optimizer that a function does anything in particular. For example, in CUDA code clang marks all functions as convergent, and then relies on LLVM to remove the attr where it can prove that the function is not convergent. But this analysis is not complete (I can provide examples if this is needed, but one obvious case is, all inline asm is opaque and assumed to be convergent).

Nonetheless I agree with Matt that this optimization is correct, just for a different reason. As spec'ed in the langref, you cannot *add* control-flow dependencies to calls to convergent functions. You are allowed to *remove* dependencies, however. This transformation does exactly that.

tstellar abandoned this revision.Jul 5 2017, 3:05 AM