[llvm-bugs] [Bug 33481] New: [AArch64][opt] Induction variable pass missed sext elimination opportunity

[via llvm-bugs]

https://bugs.llvm.org/show_bug.cgi?id=33481

            Bug ID: 33481
           Summary: [AArch64][opt] Induction variable pass missed sext
                    elimination opportunity
           Product: tools
           Version: 4.0
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: opt
          Assignee: unassignedbugs at nondot.org
          Reporter: john.russo at nxp.com
                CC: llvm-bugs at lists.llvm.org

Created attachment 18650
  --> https://bugs.llvm.org/attachment.cgi?id=18650&action=edit
C test file

LLVM/CLANG tag "release_40", target AArch64 (and any 64-bit target whose int
size is 32 and pointer size
is 64).

Given the attached test case, use the following script or compile with:

OPT=-O3
INFO="-mllvm -debug"
INFO2="-mllvm -debug-only=instcombine"
INFO3="-mllvm -print-after-all"
INFO4="-mllvm -debug-only=indvars"
NOINFO=
CLANG_PATH=<your-path>/bin
${CLANG_PATH}/clang -v -target aarch64 -S -emit-llvm -fshort-wchar ${NOINFO}
${OPT}  -std=c99 test.c 

Note, the TakeAddr function is added to disable DeadArgElimination, which
oversimplifies the test case.

Is this an optimization opportunity in Induction Variable simplification?


Could the sequence:

Function PadInputTemplate:

*** IR Dump After Induction Variable Simplification ***
for.body.us:                                      ; preds =
%for.body.us.preheader, %for.cond14.for.cond.cleanup16_crit_edge.us
  %indvars.iv = phi i64 [ 0, %for.body.us.preheader ], [ %indvars.iv.next,
%for.cond14.for.cond.cleanup16_crit_edge.us ]
  %3 = trunc i64 %indvars.iv to i32
  %mul4.us = mul i32 %mul3, %3
  %idx.ext.us = sext i32 %mul4.us to i64
  %add.ptr.us = getelementptr inbounds float, float* %input, i64 %idx.ext.us

be simplified to: (%mul3 has been constant propagated to 961 by inlining)

Function PadInput_96_27_27_2 (after inlining):

for.body.us.i:                                    ; preds =
%for.cond14.for.cond.cleanup16_crit_edge.us.i, %entry
  %indvars.iv.i = phi i64 [ 0, %entry ], [ %indvars.iv.next.i,
%for.cond14.for.cond.cleanup16_crit_edge.us.i ]
  %no_sext = mul nuw nsw i64 %indvars.iv.i, 961 
  %add.ptr8.us.i = getelementptr inbounds float, float* %output, i64 %no_sext

Since the sext is not eliminated in the current case, this eventually leads to
shl,ashr instructions which are combined with the mul leading to inefficient
code.

The AArch64 backend may efficiently code gen this, but the issue is generic to
other target whose int size is 32 and pointer size is 64.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20170616/cc94bcdc/attachment-0001.html>