[LLVMdev] [RFC] Invariants in LLVM

[Andrew Trick]

> On Jul 17, 2014, at 2:44 PM, Chandler Carruth <chandlerc at google.com> wrote:
> 
> I worry about the maintenance cost of this in the optimizer.
> 
> As long as we don't go "crazy" trying to recover the performance, it should be OK. Hal has already put together the patches needed for his current approach. We'll likely have to tweak this approach a little, but we don't need to go throguh and change every single hasOneUse() check to do something special with these invariants (or assumptions). 

My main concern was the impact on use-list iteration and hasOneUse() patterns, and the potential burden on the rest of the optimizer because we often need to check for ephemeral values. Is there any way to check that a use is ephemeral? The potential for silently defeating optimizations when you add the intrinsics is also worrisome. It could lead to surprising results when someone adds a new invariant that is supposed to improve performance.

That said, I put a lot of weight in having an implementation. If you can run experiments where you add a significant number of invariants and don’t see performance regressions, then I’d be convinced. If we can make it work in the current code base, then maintaining it should be doable.

It could also be a problem that we introduce a call that potentially writes memory, but that is less subtle than the use-list problem.

On all the other points raised in the thread, I agree with Chandler and Philip’s comments.

-Andy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140718/fa8dc8af/attachment.html>