[LLVMdev] LICM and SCEV AA?

[Andrew Trick]

> On Nov 5, 2013, at 11:51 AM, Andrew Trick <atrick at apple.com> wrote:
> 
> 
>> 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.
> 
> 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.
> 
> 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.

...that said. If SCEV AA is much simpler, and we are confident that it will be invalidated before anything else uses it. (InstCombine may do it), then it's a straightforward compile time vs perf trade off. That can be measured. 

Andy

> 
> -Andy
> 
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20131105/126e0128/attachment.html>