[PATCH] D15124: Use @llvm.invariant.start/end intrinsics to extend the meaning of basic AA's pointsToConstantMemory(), for GVN-based load elimination purposes [Local objects only]

[Hal Finkel via llvm-commits]

----- Original Message -----

> From: "Daniel Berlin" <dberlin at dberlin.org>
> To: "Hal Finkel" <hfinkel at anl.gov>
> Cc: "Chandler Carruth" <chandlerc at gmail.com>,
> reviews+D15124+public+ddba332c127856cb at reviews.llvm.org, "Larisse
> Voufo" <lvoufo at gmail.com>, "llvm-commits"
> <llvm-commits at lists.llvm.org>
> Sent: Wednesday, January 13, 2016 9:21:22 AM
> Subject: Re: [PATCH] D15124: Use @llvm.invariant.start/end intrinsics
> to extend the meaning of basic AA's pointsToConstantMemory(), for
> GVN-based load elimination purposes [Local objects only]

> > This works if there's only one start. If there are multiple starts,
> > then we need only the set to dominate, not any individual one.
> 

> > invariant_start invariant_start
> 
> > | |
> 
> > |________________ |
> 
> > |
> 
> > load
> 
> > |
> 
> > ret
> 

> > At least in theory, this is fine too. The "right" way to solve this
> > might be to set it up as a lattice/dataflow problem on the CFG, and
> > then iterate until convergence (which should happen in two
> > iterations, aside perhaps from pathological cases).
> 
> Yes, you can't solve this sparsely without virtual phi nodes for the
> data, and it's not clear to me it's worth the cost of doing that.

> (I've seen compilers that do it for extra data they want to use
> during ssa optimizations, but ... so far i'd say not worth it)
Based on the way we're currently planning to generate these intrinsics in Clang, we probably need to worry only about the single-dominating-invariant_start case. That having been said, all alternatives, which involve doing repetitive "local" CFG walks, could well turn out to be more expensive than simply solving the problem (in full) up front (by which I really mean, in practice, upon first encountering one of the intrinsics). I don't have a particularly-good feel for how the relative expenses would turn out. I'm certainly okay with doing the easier thing first in this case, so long as it is sufficiently robust not to seem flaky. 

-Hal 

-- 

Hal Finkel 
Assistant Computational Scientist 
Leadership Computing Facility 
Argonne National Laboratory 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20160113/2606e3ad/attachment.html>