[LLVMbugs] [Bug 23517] New: UBSan breaks target intrinsics taking constants: should we fold overflow intrinsics? Where?

[bugzilla-daemon at llvm.org]

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

            Bug ID: 23517
           Summary: UBSan breaks target intrinsics taking constants:
                    should we fold overflow intrinsics? Where?
           Product: clang
           Version: trunk
          Hardware: PC
                OS: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: LLVM Codegen
          Assignee: unassignedclangbugs at nondot.org
          Reporter: ahmed.bougacha at gmail.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

Consider:

#include <arm_neon.h>
int32x2_t test(int64x2_t a) {
  return vqrshrn_n_s64(a, 31 - 2);
}

  clang -fsanitize=undefined -target arm64-apple-darwin -O0

will generate:

  %3 = call { i32, i1 } @llvm.ssub.with.overflow.i32(i32 31, i32 2)
  %4 = extractvalue { i32, i1 } %3, 0
  ...
  %vqrshrn_n1 = call <2 x i32> @llvm.aarch64.neon.sqrshrn.v2i32(<2 x i64>
%vqrshrn_n, i32 %4)


Which is not OK, and breaks various assumptions in clang and LLVM (and will
causes us to eventually crash).

With -O0, we can't expect any pass to fold these;  in fact, clang itself
assumes these intrinsics *will* take Constants, so we have to deal with this
during IR gen.

I see two alternatives:
- teach ConstantFolder to deal with overflow intrinsics (messy, because it's
implemented in terms of ConstantExprs)
- teach the UBSan clang CodeGen to do the folding (which sounds wrong)

-- 
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/20150513/64c96c4d/attachment.html>