[LLVMdev] It seems like some bug in Alias Analysis While enable useAA()

[Hal Finkel]

----- Original Message -----
> From: "Yaorong lee" <leeyr338 at gmail.com>
> To: llvmdev at cs.uiuc.edu
> Sent: Wednesday, February 26, 2014 9:50:42 AM
> Subject: [LLVMdev] It seems like some bug in Alias Analysis While enable	useAA()
> 
> 
> 
> Hi,
> An error instruction scheduling in post-ra schedule pass confused me
> a lot, I hack the code,
> and found that maybe some bug in Alias Analysis while enable useAA().
> The following is a
> piece of IR I debuged:
> 
> EntryBB:
> ...
> 1 %uBase16 = bitcast %union.VR_union* %uu_buf to [8 x i16]*
> 2 %arrayidx = bitcast %union.VR_union* %uu_buf to [8 x i16]*
> 3 store i16 -1, i16* %arrayidx, align 16
> 4 %arrayidx2 = getelementptr inbounds [8 x i16]* %uBase16, i32 0, i32
> 1
> 5 store i16 4660, i16* %arrayidx2, align 2
> ...(set the 128bit vector to uu_buf)
> 6 %vecalign = bitcast %union.VR_union* %uu_buf to ppc_fp128
> 
> 
> ; load 128bit vector from uu_buf
> 7 %data = load ppc_fp128* %vecalign, align 16
> ...
> ... (other Basic blocks)
> 
> 
> BB#4:
> 8 store i16 1000, i16* %arrayidx, align 16
> 9 store i16 1234, i16* %arrayidx2, align 16
> ... (set the 128bit vector to uu_buf)
> 10 %vecalign = bitcast %union.VR_union* %uu_buf to ppc_fp128
> 
> 
> ; load 128bit vector from uu_buf
> 11 %data = load ppc_fp128* %vecalign, align 16
> ....
> According to my understanding, all the "store" instructons which set
> the uu_buf (e.g. NO.9)
> should be "PartialAlias" with the load uu_buf instruction (NO.11).
> But after the "Codegen Prepare"
> pass , the BB#4 will be transformed to something like:
> BB#4:
> ...
> 1 %sunkaddr = ptrto %union.VR_union uu_buf to i64
> 2 %sunkaddr23 = add i64 %sunkaddr, 2
> 3 %sunkaddr24 = inttoptr i64 %sunkaddr23, align 2
> 4 store i16 1234, i16* %sunkaddr24, align 2
> ...
> 5 %vecalign = bitcast %union.VR_union* %uu_buf to ppc_fp128
> 6 %data = load ppc_fp128* %vecalign, align 16
> ...
> The Alias Analysis will return "NoAlias" for the NO.6 instruction and
> No.4 instruction (it should be PartialAlias).
> Alias Analysis stop analysising on instruction NO.3, because
> %sunkaddr24 is not a pointer!
> So, when the post-ra scheduler got "NoAlias" infomation, it would
> schedule instruction like:
> BB#4:
> ...
> 1 %sunkaddr = ptrto %union.VR_union uu_buf to i64
> 2 %sunkaddr23 = add i64 %sunkaddr, 2
> 
> 
> ; Error schedule the load instruction to this location
> 6 %data = load ppc_fp128* %vecalign, align 16
> 3 %sunkaddr24 = inttoptr i64 %sunkaddr23, align 2
> 4 store i16 1234, i16* %sunkaddr24, align 2
> ...
> 5 %vecalign = bitcast %union.VR_union* %uu_buf to ppc_fp128
> ...
> And this is an error scheduling!
> Has someone encountered this problem before?

Hi,

Thanks for reporting this. It would be great if you could post the IR that demonstrates this problem (the post CGP IR). Regardless, please file a bug. As you might be aware, I recently disabled the use of TBAA in CodeGen exactly because of problems related to this (cases where BasicAA would override TBAA would stop working after CGP, leading to miscompiles). This, however, looks like it might just be a bug in BasicAA.

 -Hal

> 
> 
> Best Regards,
> Yaorong Lee
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
> 

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