[llvm-bugs] [Bug 29118] New: LLVM O2: LLVM opt -O2 did wrong optimization happened on Power / x86.

via llvm-bugs llvm-bugs at lists.llvm.org
Wed Aug 24 01:32:41 PDT 2016


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

            Bug ID: 29118
           Summary: LLVM O2: LLVM opt -O2 did wrong optimization happened
                    on Power / x86.
           Product: new-bugs
           Version: unspecified
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: new bugs
          Assignee: unassignedbugs at nondot.org
          Reporter: bluechristlove at 163.com
                CC: llvm-bugs at lists.llvm.org
    Classification: Unclassified

Considered following case:

[code]

template <class _Tp, int _Size>
struct __attribute__ ((__type_visibility__("default"))) array
{
    typedef _Tp value_type;
    value_type __elems_[_Size > 0 ? _Size : 1];

};

template <class _T1, class _T2 = _T1>
struct __equal_to
{
    __attribute__ ((__visibility__("hidden"), __always_inline__)) bool
operator()(const _T1& __x, const _T1& __y) const {return __x == __y;}
    __attribute__ ((__visibility__("hidden"), __always_inline__)) bool
operator()(const _T1& __x, const _T2& __y) const {return __x == __y;}
    __attribute__ ((__visibility__("hidden"), __always_inline__)) bool
operator()(const _T2& __x, const _T1& __y) const {return __x == __y;}
    __attribute__ ((__visibility__("hidden"), __always_inline__)) bool
operator()(const _T2& __x, const _T2& __y) const {return __x == __y;}
};

template <class _T1>
struct __equal_to<_T1, _T1>
{
    __attribute__ ((__visibility__("hidden"), __always_inline__))
    bool operator()(const _T1& __x, const _T1& __y) const {return __x == __y;}
};

template <class _T1>
struct __equal_to<const _T1, _T1>
{
    __attribute__ ((__visibility__("hidden"), __always_inline__))
    bool operator()(const _T1& __x, const _T1& __y) const {return __x == __y;}
};

template <class _T1>
struct __equal_to<_T1, const _T1>
{
    __attribute__ ((__visibility__("hidden"), __always_inline__))
    bool operator()(const _T1& __x, const _T1& __y) const {return __x == __y;}
};


template <class _InputIterator1, class _InputIterator2, class _BinaryPredicate>
inline __attribute__ ((__visibility__("hidden"), __always_inline__))
bool
equal(_InputIterator1 __first1, _InputIterator1 __last1, _InputIterator2
__first2, _BinaryPredicate __pred)
{
    for (; __first1 != __last1; ++__first1, (void) ++__first2)
        if (!__pred(*__first1, *__first2))
            return false;
    return true;
}


template <class _InputIterator1, class _InputIterator2>
inline __attribute__ ((__visibility__("hidden"), __always_inline__))
bool
equal(_InputIterator1 __first1, _InputIterator1 __last1, _InputIterator2
__first2)
{
    typedef  decltype(*__first1) __v1;
    typedef  decltype(*__first2) __v2;
    return equal(__first1, __last1, __first2, __equal_to<__v1, __v2>());
}

template <class _Tp, int _Size>
inline __attribute__ ((__visibility__("hidden"), __always_inline__))
bool
operator==(const array<_Tp, _Size>& __x, const array<_Tp, _Size>& __y)
{
    return equal(__x.__elems_, __x.__elems_ + _Size, __y.__elems_);
}

int main()
{
  typedef array<char, 10> Con;
  Con v0;
  __builtin_printf("%d\n", v0 == v0);
}

[/code]

use clang trunk -std=c++11 -O2

wuzhao at lep82446v:~/wk.dev$ clang++ --version
clang version 4.0.0 (trunk)
Target: powerpc64le-unknown-linux-gnu
Thread model: posix

wuzhao at lep82446v:~/wk.dev$ clang++ x.C -std=c++11 -O0
wuzhao at lep82446v:~/wk.dev$ ./a.out
1

but on -O2:
wuzhao at lep82446v:~/wk.dev$ clang++ x.C -std=c++11 -O2
wuzhao at lep82446v:~/wk.dev$ ./a.out
0

If we use O0 LLVM IR and use llvm-opt to do O2 optimization.

we can find like this:

block-frequency: main
=====================
reverse-post-order-traversal
 - 0: _ZeqIcLi10EEbRK5arrayIT_XT0_EES4_.exit
loop-detection
compute-mass-in-function
 - node: _ZeqIcLi10EEbRK5arrayIT_XT0_EES4_.exit
  => mass:  ffffffffffffffff
float-to-int: min = 1.0, max = 1.0, factor = 8.0
 - _ZeqIcLi10EEbRK5arrayIT_XT0_EES4_.exit: float = 1.0, scaled = 8.0, int = 8
block-frequency-info: main
 - _ZeqIcLi10EEbRK5arrayIT_XT0_EES4_.exit: float = 1.0, int = 8



INSTCOMBINE ITERATION #1 on main
IC: ADDING: 2 instrs to worklist
IC: Visiting:   %call1 = call signext i32 (i8*, ...) @printf(i8* getelementptr
inbounds ([4 x i8], [4 x i8]* @.str, i64 0, i64 0), i32 signext 0)
IC: Visiting:   ret i32 0
SLP: Analyzing blocks in main.


INSTCOMBINE ITERATION #1 on main
IC: ADDING: 2 instrs to worklist
IC: Visiting:   %call1 = call signext i32 (i8*, ...) @printf(i8* getelementptr
inbounds ([4 x i8], [4 x i8]* @.str, i64 0, i64 0), i32 signext 0)
IC: Visiting:   ret i32 0


INSTCOMBINE ITERATION #1 on main
IC: ADDING: 2 instrs to worklist
IC: Visiting:   %call1 = call signext i32 (i8*, ...) @printf(i8* getelementptr
inbounds ([4 x i8], [4 x i8]* @.str, i64 0, i64 0), i32 signext 0)
IC: Visiting:   ret i32 0

We can find that O2 made the result be 0. But if we use O1:

INSTCOMBINE ITERATION #1 on main
IC: ADDING: 2 instrs to worklist
IC: Visiting:   %call1 = call signext i32 (i8*, ...) @printf(i8* getelementptr
inbounds ([4 x i8], [4 x i8]* @.str, i64 0, i64 0), i32 signext 1)
IC: Visiting:   ret i32 0


INSTCOMBINE ITERATION #1 on main
IC: ADDING: 2 instrs to worklist
IC: Visiting:   %call1 = call signext i32 (i8*, ...) @printf(i8* getelementptr
inbounds ([4 x i8], [4 x i8]* @.str, i64 0, i64 0), i32 signext 1)
IC: Visiting:   ret i32 0


INSTCOMBINE ITERATION #1 on main
IC: ADDING: 2 instrs to worklist
IC: Visiting:   %call1 = call signext i32 (i8*, ...) @printf(i8* getelementptr
inbounds ([4 x i8], [4 x i8]* @.str, i64 0, i64 0), i32 signext 1)
IC: Visiting:   ret i32 0

It is fine.

So, O2 did something wrong. Not only on PowerPC but also on x86.

Addtionally, Clang 3.5 is OK with O2.

Similiar Bugs: https://llvm.org/bugs/show_bug.cgi?id=29085

-- 
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/20160824/b6c008c4/attachment.html>


More information about the llvm-bugs mailing list