Wrong value for sext i1 true in BasicAliasAnalysis

Hal Finkel hfinkel at anl.gov
Tue Dec 23 16:19:57 PST 2014


----- Original Message -----
> From: "Nicholas White" <n.j.white at gmail.com>
> To: "Hal Finkel" <hfinkel at anl.gov>
> Cc: "Yin Ma" <yinma at codeaurora.org>, "llvm commits" <llvm-commits at cs.uiuc.edu>, "Arnold Schwaighofer"
> <aschwaighofer at apple.com>, "Andrew Trick" <atrick at apple.com>
> Sent: Tuesday, December 23, 2014 4:47:22 PM
> Subject: Re: Wrong value for sext i1 true in BasicAliasAnalysis
> 
> > That's because sext64(zext64(v)) == zext64(v)
> > sext(zext(y)) is not interesting because the sign bit is known to
> > be zero
> Ach, I missed this! This means a VariableGEPIndex only needs two
> counters, one for the number of bits SExt'ed and one for the number
> of bits ZExt'ed - and the ExtensionKind enum can be removed
> entirely. I've updated http://reviews.llvm.org/D6682 - it's much
> cleaner (+174,-57 plus tests) now.

Sounds good. I think this is moving in the right direction.

 -Hal

> 
> > How are you getting a MustAlias?
> Hm, I can't reproduce this. On stepping through that example in a
> build of 3f2027522c83fcb4fd8629b6395cec82bfda9cd1 it seems the
> PartialAlias decision comes because GetLinearExpression doesn't look
> through the two sext instructions (%sext.1 and %sext.2), so
> GetIndexDifference doesn't cancel the two expressions out. This
> means that it doesn't decide that %a and %b NoAlias in the below:
> 
> define void @test_zext_sext_amounts255(i8* %mem) {
> %sext.1 = sext i8 255 to i16
> %sext.zext.1 = zext i16 %sext.1 to i64
> %sext.2 = sext i8 255 to i32
> %sext.zext.2 = zext i32 %sext.2 to i64
> %a = getelementptr inbounds i8* %mem, i64 %sext.zext.1
> %b = getelementptr inbounds i8* %mem, i64 %sext.zext.2
> ret void
> }
> 
> .> Expecting it to work just as well on un-optimized IR is not
> reasonable.
> OK, that makes sense.
> 
> Thanks -
> 
> 
> Nick
> 

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



More information about the llvm-commits mailing list