[llvm] r270629 - [LoopUnrollAnalyzer] Fix a crash in UnrolledInstAnalyzer::visitCastInst.

Michael Zolotukhin via llvm-commits llvm-commits at lists.llvm.org
Tue May 24 18:24:19 PDT 2016


> On May 24, 2016, at 6:07 PM, Eli Friedman <eli.friedman at gmail.com> wrote:
> 
> On Tue, May 24, 2016 at 5:57 PM, Michael Zolotukhin <mzolotukhin at apple.com <mailto:mzolotukhin at apple.com>> wrote:
> 
>> On May 24, 2016, at 5:47 PM, Eli Friedman <eli.friedman at gmail.com <mailto:eli.friedman at gmail.com>> wrote:
>> How are you getting into a situation where "V.getType() != SimplifiedValues.lookup(V).getType()"?  It seems like there's an underlying problem which is getting ignored here.
> It happens when SCEV analyzes an instruction like
> %offset = getelementptr inbounds float, float* null, i32 3
> 
> Ah, I see, SCEVConstant::getValue returns a ConstantInt.  That's probably reasonable from the perspective of SCEV, since it fundamentally always works with integers.
Yeah, that’s what I thought too.
> 
> When asked for a value at some iteration, SCEV considers ‘null' as 0 and returns, for instance, ‘i32 24’. I’m not sure if it’s incorrect, that’s why I fixed it in this spot.
> 
> Maybe you could construct an inttoptr constant expression in UnrolledInstAnalyzer::simplifyInstWithSCEV instead of trying to recover later?
That would require adding a special case handling to simplifyInstWithSCEV, which I prefer to avoid. Currently we don’t look at what type of instruction we’re analyzing at all - we completely rely on SCEV there.

Michael
> 
> -Eli

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20160524/dd6d3555/attachment.html>


More information about the llvm-commits mailing list