llvm dev - Apr 2016 - RFC: Generalize AssumptionCache to AxiomCache

Hi all,

Guard intrinsics[0] are similar in nature to Assume intrinsics, in
that the condition passed to a guard intrinsic call is known to be
true at locations dominated (but *not* post-dominated) by the
call[1].  I'd like to re-use the AssumptionCache infrastructure that
already exists to teach the mid level optimizer to exploit this
property.

The steps I want to take are (not necessarily in this order or split
up this way):

  - Rename AssumptionCache to AxiomCache (or something similar)
  - Maintain two lists in AxiomCache, one for assumptions (exactly the
    same as today) and other for guards (`AxiomCache::guards()`)
  - Change places that check check the `assumptions()` list to also
    check the newly added `guards()` list

I want to maintain `assumptions()` and `guards()` separately since, as
noted above, the way they can be used by the optimizer is different
(guards don't necessarily imply their condition on post-dominance).

Does that sound reasonable?

-- Sanjoy

[0]:
http://llvm.org/docs/LangRef.html#llvm-experimental-guard-intrinsic

[1]: The guard intrinsics checks the condition at runtime and
deoptimizes the current blob of compiled code if the condition is
false.

Hi Sanjoy,

I agree what reusing the existing infrastructure makes sense. Why not just keep
one list in the assumption cache and provide a way for the client to filter
should it care whether or not post-dominance truth is implied. I assume ;) that
unless the lists are going to large and clients are likely to want to filter
then a single list will be more efficient. What do you think?

 -Hal

----- Original Message -----
> From: "Sanjoy Das" <sanjoy at playingwithpointers.com>
> To: "llvm-dev" <llvm-dev at lists.llvm.org>
> Cc: hfinkel at anl.gov
> Sent: Wednesday, April 27, 2016 5:43:33 PM
> Subject: RFC: Generalize AssumptionCache to AxiomCache
> 
> Hi all,
> 
> Guard intrinsics[0] are similar in nature to Assume intrinsics, in
> that the condition passed to a guard intrinsic call is known to be
> true at locations dominated (but *not* post-dominated) by the
> call[1].  I'd like to re-use the AssumptionCache infrastructure that
> already exists to teach the mid level optimizer to exploit this
> property.
> 
> The steps I want to take are (not necessarily in this order or split
> up this way):
> 
>   - Rename AssumptionCache to AxiomCache (or something similar)
>   - Maintain two lists in AxiomCache, one for assumptions (exactly
>   the
>     same as today) and other for guards (`AxiomCache::guards()`)
>   - Change places that check check the `assumptions()` list to also
>     check the newly added `guards()` list
> 
> I want to maintain `assumptions()` and `guards()` separately since,
> as
> noted above, the way they can be used by the optimizer is different
> (guards don't necessarily imply their condition on post-dominance).
> 
> Does that sound reasonable?
> 
> -- Sanjoy
> 
> [0]:
> http://llvm.org/docs/LangRef.html#llvm-experimental-guard-intrinsic
> 
> [1]: The guard intrinsics checks the condition at runtime and
> deoptimizes the current blob of compiled code if the condition is
> false.
> 
-- 
Hal Finkel
Assistant Computational Scientist
Leadership Computing Facility
Argonne National Laboratory

Hi Hal,

On Sat, Apr 30, 2016 at 1:13 PM, Hal Finkel <hfinkel at anl.gov>
wrote:
> I agree what reusing the existing infrastructure makes sense. Why not just
keep one list in the assumption cache and provide a way for the client to filter
should it care whether or not post-dominance truth is implied. I assume ;) that
unless the lists are going to large and clients are likely to want to filter
then a single list will be more efficient.
Sounds great, I'll put some patches up for review soon.

-- Sanjoy