[LLVMdev] [RFC] Invariants in LLVM

[Hal Finkel]

----- Original Message -----
> From: "Andrew Trick" <atrick at apple.com>
> To: "Chandler Carruth" <chandlerc at google.com>
> Cc: "LLVM Dev" <llvmdev at cs.uiuc.edu>
> Sent: Friday, July 18, 2014 2:49:30 AM
> Subject: Re: [LLVMdev] [RFC] Invariants in LLVM
> 
> 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.

Regarding hasOneUse(), I propose that we not change it at all. The philosophy that I'd like to experiment with is, "if the invariant is worth having, then it is worth keeping." That means not performing optimizations that will necessitate removal of the invariant (which I think we'd need to do if we somehow update hasOneUse() to ignore ephemeral values).

That having been said, there are certainly times when we'd like to ignore ephemeral values (such as when we do cost estimates for inlining, loop unrolling, etc.), and we do need to worry about efficiency there. It may turn out that the current scheme needs enhancement to be sufficiently efficient.

> 
> 
> 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.

Yes, and this is necessary to maintain control dependencies. However, I'm updated BasicAA to return NoModRef for any particular Loc-CS and CS-CS query involving an invariant. So, although it writes to somewhere unknown, it won't alias with anywhere in particular, and so hopefully it will not affect code motion for memory accesses for which we have location information.

Thanks again,
Hal

> 
> 
> On all the other points raised in the thread, I agree with Chandler
> and Philip’s comments.
> 
> 
> -Andy
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
> 

-- 
Hal Finkel
Assistant Computational Scientist
Leadership Computing Facility
Argonne National Laboratory