I'm curious why I am seeing this: *%uglygep18.sum = add i32 %lsr_iv8, %tmp45* %scevgep19 = getelementptr i8* %parBits_017, i32 %uglygep18_sum %scevgep1920 = bitcast i8* %scevgep19 to i16* %tmp78 = load i16* %scevgep1920, align 2 * %uglygep14.sum = add i32 %lsr_iv8, %tmp45* %scevgep15 = getelementptr i8* %extIn_013, i32 %uglygep14_sum %scevgep1516 = bitcast i8* %scevgep15 to i16* %tmp79 = load i16* %scevgep1516, align 2 %conv93.i.i = sext i16 %tmp79 to i32 *%uglygep.sum = add i32 %lsr_iv8, %tmp45* %scevgep11 = getelementptr i8* %sysBits_010, i32 %uglygep_sum You can see here that "add i32 %lsr_iv8, %tmp45" is done multiple times, appearing that there are two redundant add operations that are not needed yet are generated? Thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20121017/5abebfc6/attachment.html>
On Wed, Oct 17, 2012 at 1:22 PM, Ryan Taylor <ryta1203 at gmail.com> wrote:> I'm curious why I am seeing this: > > %uglygep18.sum = add i32 %lsr_iv8, %tmp45 > %scevgep19 = getelementptr i8* %parBits_017, i32 %uglygep18_sum > %scevgep1920 = bitcast i8* %scevgep19 to i16* > %tmp78 = load i16* %scevgep1920, align 2 > %uglygep14.sum = add i32 %lsr_iv8, %tmp45 > %scevgep15 = getelementptr i8* %extIn_013, i32 %uglygep14_sum > %scevgep1516 = bitcast i8* %scevgep15 to i16* > %tmp79 = load i16* %scevgep1516, align 2 > %conv93.i.i = sext i16 %tmp79 to i32 > %uglygep.sum = add i32 %lsr_iv8, %tmp45 > %scevgep11 = getelementptr i8* %sysBits_010, i32 %uglygep_sum > > You can see here that "add i32 %lsr_iv8, %tmp45" is done multiple times, > appearing that there are two redundant add operations that are not needed > yet are generated?CodeGenPrepare manipulates GEPs in a way that can expose redundancy where it wasn't obvious before. -Eli
Eli, Thanks. So I'm unclear exactly which llvm opt will exhibit copy prop. behavior? It seems to me that codegenprepare is doing a useful thing (for me, since I'm just using the llvm IR and not going to backend, providing it's "exposing" and not simply "adding for layout for CodeGen opts" (or something similar to this)? Thanks. On Wed, Oct 17, 2012 at 1:44 PM, Eli Friedman <eli.friedman at gmail.com>wrote:> On Wed, Oct 17, 2012 at 1:22 PM, Ryan Taylor <ryta1203 at gmail.com> wrote: > > I'm curious why I am seeing this: > > > > %uglygep18.sum = add i32 %lsr_iv8, %tmp45 > > %scevgep19 = getelementptr i8* %parBits_017, i32 %uglygep18_sum > > %scevgep1920 = bitcast i8* %scevgep19 to i16* > > %tmp78 = load i16* %scevgep1920, align 2 > > %uglygep14.sum = add i32 %lsr_iv8, %tmp45 > > %scevgep15 = getelementptr i8* %extIn_013, i32 %uglygep14_sum > > %scevgep1516 = bitcast i8* %scevgep15 to i16* > > %tmp79 = load i16* %scevgep1516, align 2 > > %conv93.i.i = sext i16 %tmp79 to i32 > > %uglygep.sum = add i32 %lsr_iv8, %tmp45 > > %scevgep11 = getelementptr i8* %sysBits_010, i32 %uglygep_sum > > > > You can see here that "add i32 %lsr_iv8, %tmp45" is done multiple times, > > appearing that there are two redundant add operations that are not needed > > yet are generated? > > CodeGenPrepare manipulates GEPs in a way that can expose redundancy > where it wasn't obvious before. > > -Eli >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20121017/dc84f81a/attachment.html>
On Oct 17, 2012, at 1:22 PM, Ryan Taylor <ryta1203 at gmail.com> wrote:> I'm curious why I am seeing this: > > %uglygep18.sum = add i32 %lsr_iv8, %tmp45 > %scevgep19 = getelementptr i8* %parBits_017, i32 %uglygep18_sum > %scevgep1920 = bitcast i8* %scevgep19 to i16* > %tmp78 = load i16* %scevgep1920, align 2 > %uglygep14.sum = add i32 %lsr_iv8, %tmp45 > %scevgep15 = getelementptr i8* %extIn_013, i32 %uglygep14_sum > %scevgep1516 = bitcast i8* %scevgep15 to i16* > %tmp79 = load i16* %scevgep1516, align 2 > %conv93.i.i = sext i16 %tmp79 to i32 > %uglygep.sum = add i32 %lsr_iv8, %tmp45 > %scevgep11 = getelementptr i8* %sysBits_010, i32 %uglygep_sum > > You can see here that "add i32 %lsr_iv8, %tmp45" is done multiple times, appearing that there are two redundant add operations that are not needed yet are generated?That's LSR, as you can see from the variable names ;) It might think that load(Base + Index) is a legal addressing mode for your target. -disable-lsr might be the right thing for you anyway. Incidentally, MachineCSE could clean this up if it doesn't get folded into the address, but like LSR, it tries hard not to increase register pressure. -Andy -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20121019/1d350dc9/attachment.html>
That solves the issue but it seems odd to me that instcombine doesn't take care of it? So is this just a setup for the backend? If not, seems like if there is a possibility that lsr could create these redundant operations, should it not clean itself up? Or am I mistaken? On Fri, Oct 19, 2012 at 1:29 PM, Andrew Trick <atrick at apple.com> wrote:> > On Oct 17, 2012, at 1:22 PM, Ryan Taylor <ryta1203 at gmail.com> wrote: > > I'm curious why I am seeing this: > > *%uglygep18.sum = add i32 %lsr_iv8, %tmp45* > %scevgep19 = getelementptr i8* %parBits_017, i32 %uglygep18_sum > %scevgep1920 = bitcast i8* %scevgep19 to i16* > %tmp78 = load i16* %scevgep1920, align 2 > * %uglygep14.sum = add i32 %lsr_iv8, %tmp45* > %scevgep15 = getelementptr i8* %extIn_013, i32 %uglygep14_sum > %scevgep1516 = bitcast i8* %scevgep15 to i16* > %tmp79 = load i16* %scevgep1516, align 2 > %conv93.i.i = sext i16 %tmp79 to i32 > *%uglygep.sum = add i32 %lsr_iv8, %tmp45* > %scevgep11 = getelementptr i8* %sysBits_010, i32 %uglygep_sum > > You can see here that "add i32 %lsr_iv8, %tmp45" is done multiple times, > appearing that there are two redundant add operations that are not needed > yet are generated? > > > That's LSR, as you can see from the variable names ;) It might think that > load(Base + Index) is a legal addressing mode for your target. -disable-lsr > might be the right thing for you anyway. > > Incidentally, MachineCSE could clean this up if it doesn't get folded into > the address, but like LSR, it tries hard not to increase register pressure. > > -Andy >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20121019/357562ac/attachment.html>
Possibly Parallel Threads
- [LLVMdev] Redundant Add Operation in Code Generation?
- [LLVMdev] Redundant Add Operation in Code Generation?
- [LLVMdev] Redundant Add Operation in Code Generation?
- [LLVMdev] Redundant Add Operation in Code Generation?
- [LLVMdev] Redundant Add Operation in Code Generation?