Yaorong lee
2014-Feb-26 15:50 UTC
[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?
Best Regards,
Yaorong Lee
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20140226/c0873eb4/attachment.html>
Arnold Schwaighofer
2014-Feb-26 17:51 UTC
[LLVMdev] It seems like some bug in Alias Analysis While enable useAA()
Hi Lee, can you reproduce the bug by dumping the IR to a file and running “opt -basicaa -aa-eval -print-all-alias-modref-info < test-case.ll”. This would help in debugging this problem. Thanks, Arnold On Feb 26, 2014, at 7:50 AM, Yaorong lee <leeyr338 at gmail.com> wrote:> 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? > > 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
2014-Feb-26 18:11 UTC
[LLVMdev] It seems like some bug in Alias Analysis While enable useAA()
----- 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