[LLVMdev] LICM and SCEV AA?

[Hal Finkel]

----- Original Message -----
> 
> 
> 
> On Nov 5, 2013, at 11:42 AM, Renato Golin < renato.golin at linaro.org >
> wrote:
> 
> 
> 
> On 2 November 2013 05:59, Hal Finkel < hfinkel at anl.gov > wrote:
> 
> 
> 
> 
> 
> 
> > I would be scared to enable SCEV AA because it's not well tested
> 
> This seems like a solvable problem. SCEV AA itself is something like
> 30 lines of non-boilerplate code, and essentially does one thing
> (calls getMinusSCEV in both directions and uses getUnsignedRange on
> the result). We should look it over.
> 
> 
> 
> If SCEV AA itself is conservative, the worst that can happen is that
> it won't detect all cases it could, but we can extend it later. It
> seems to me that this piece of code was added as an experiment and
> never updated, but since it's already there, we could come up with a
> few tests that would check the boundaries of a 30 loc piece, no?
> 
> Yes SCEV AA was an experiment. The reason it wasn’t ripped out is
> that it’s potentially useful. The worst that will happen is that
> passes will crash in *very* confusing ways. SCEVs will be evaluated
> early, not properly updated, and someone will try to expand them.
> You won’t hit this problems with simple testing.

FWIW, it looks like the other passes in that group of passes preserve SE by calling forgetLoop. Nevertheless, I'm certainly sympathetic to the augment that the SE-preservation property of these passes may essentially be untested.

> 
> 
> I’m not opposed to making SCEV AA a reliable thing, but I’m not sure
> what “fundamental problems” we’ll hit along the way.

Fair enough.

> 
> 
> My primary objection is that I don’t think SCEV should run before the
> LICM loop pass manager. It’s to expensive in terms of compile time
> and does have maintenance burden. I’m not yet aware of any long-term
> need to have SCEV running at this point. If we’re only talking about
> disambiguating constant array indices with loop variant ones with
> constant bounds, there might be a simpler way to handle it.

I agree; I just wanted to have some discussion about yet-again growing the number of BasicAA heuristics when a more-systematic solution exists.

Thanks again,
Hal

> 
> 
> -Andy
> 

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