[LLVMdev] [RFC] Invariants in LLVM

[Chandler Carruth]

On Thu, Jul 17, 2014 at 4:39 PM, Hal Finkel <hfinkel at anl.gov> wrote:

> Some points for discussion [by Philip, edited slightly by me]:
>
>  1. The current patches remove llvm.invariant(undef) as dead. Would it be
> better to transform this into 'unreachable' as is done for
> llvm.invariant(false).
>

I strongly thing "yes". With undef, we are granted permission to chose the
most useful value for optimization which is 'false' here.


>  2. Would adding a canonicalization of if(c) { unreachable } to
> llvm.invariant(c) would be worthwhile?
>

There was a long and painful attempt to implement invariants based on the
branch-to-unreachable pattern. It didn't work. I don't expect these
patterns to show up often organically and to go away too soon in the
optimizer to be useful. The whole point of 'llvm.invariant' instead of the
if construct is to distinguish between the case the optimizer should try to
remove (a branch to unreachable) and the case the optimizer should try to
preserve because of some specific utility. We shouldn't lose this important
distinction.


>
> Finally, I'd like to mention that alternate schemes are certainly possible:
>
>  1. We could 'hide' all invariants inside dominating blocks guarded by
> never-true conditional branches (this has the benefit of being able to
> express invariants using expressions that normally might have side effects,
> and could simplify the process of finding applicable invariants) [a
> suggestion by Richard and Nick].
>

I'm really concerned about the increased complexity and cost of invariants
in this pattern. I would like to go with the simpler and less intrusive
design until we have some compelling evidence that we need to support the
more general form.


>
>  2. We might want to have passes precompute the Value->(set of Invariants)
> map, and update it as necessary instead of doing transitive-user searches
> [a suggestion by Chandler].
>

I think this is mostly just a small API tweak to make the code more
maintainable. I'm specifically *not* imagining this as a formal analysis
pass or anything of the sort.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140717/4167d72e/attachment.html>