[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