Bug 16358: simplify SCEVs with assumptions

[Sebastian Pop]

Andrew Trick wrote:
> I'm breaking SCEV into two parts:
> (a) map IR values to canonical SCEVs
> (b) query trip count, dependence analysis, etc.
> 

Querying the trip count is part of (a). Once the niter of a loop is computed, it
is used to compute other SCEVs in step (a).

I agree that performing SCEV simplification on a user of SCEV like the data
dependence analysis in (b) would not feed back the SCEV analysis.

> Simplification would happen in both. The results of both can be cached. I'm
> suggesting that (a) remain insensitive to the query context, so the cache is
> very simple. The cache for (b) would need to store any assumptions along with
> the result.

If we use quasts to represents solutions, we could reuse the existing "could not
compute" node to mean "could not compute, unless the assumptions hold, in which
case the SCEV looks like this...". We could attach to the "could not compute"
node the quast that provides extra information requiring users to version the
code.

The intent is to avoid modifications to all the places already matching "could
not compute". In the special cases we are interested in handling the extra
assumptions with a runtime check, we would handle the extra information that is
provided in the quast.

This would require some incremental modifications to the SCEV analysis in all
the places where the SCEV computation "gives up" generating SCEVCouldNotCompute.

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation