[LLVMbugs] [Bug 15011] New: Clang coerces many extended vector types of length 1 to i32/i64.

[bugzilla-daemon at llvm.org]

http://llvm.org/bugs/show_bug.cgi?id=15011

             Bug #: 15011
           Summary: Clang coerces many extended vector types of length 1
                    to i32/i64.
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: LLVM Codegen
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: mgottesman at apple.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified


After filing PR15009 and PR15010 I got curious what would happen if I compiled
with ext_vector_types of size 1. The test file was:

----
typedef int int1 __attribute__((ext_vector_type(1)));
typedef unsigned uint1 __attribute__((ext_vector_type(1)));
typedef float float1 __attribute__((ext_vector_type(1)));
typedef long long llong1 __attribute__((ext_vector_type(1)));
typedef double double1 __attribute__((ext_vector_type(1)));

int1 test(int1 x, int1 y) {
  return x + y;
}

uint1 test1(uint1 x, uint1 y) {
  return x + y;
}

float1 test3(float1 x, float1 y) {
  return x + y;
}

llong1 test4(llong1 x, llong1 y) {
  return x + y;
}

double1 test5(double1 x, double1 y) {
  return x + y;
}
----

The resulting IR is after running 'clang -c test.c -emit-llvm -S -o - | opt
-sroa -instcombine -o - -S' (just running the opt passes to clean things up a
little bit so this PR is not that long).

----
; ModuleID = '<stdin>'
target datalayout =
"e-p:64:64:64-i1:8:8-i8:8:8-i16:16:16-i32:32:32-i64:64:64-f32:32:32-f64:64:64-v64:64:64-v128:128:128-a0:0:64-s0:64:64-f80:128:128-n8:16:32:64-S128"
target triple = "x86_64-apple-macosx10.8.0"

define i32 @test(i32 %x.coerce, i32 %y.coerce) nounwind uwtable ssp {
entry:
  %0 = add i32 %x.coerce, %y.coerce
  ret i32 %0
}

define i32 @test1(i32 %x.coerce, i32 %y.coerce) nounwind uwtable ssp {
entry:
  %0 = add i32 %x.coerce, %y.coerce
  ret i32 %0
}

define i32 @test3(i32 %x.coerce, i32 %y.coerce) nounwind uwtable ssp {
entry:
  %0 = bitcast i32 %x.coerce to float
  %1 = bitcast i32 %y.coerce to float
  %2 = fadd float %0, %1
  %3 = bitcast float %2 to i32
  ret i32 %3
}

define i64 @test4(i64 %x.coerce, i64 %y.coerce) nounwind uwtable ssp {
entry:
  %0 = add i64 %x.coerce, %y.coerce
  ret i64 %0
}

define <1 x double> @test5(<1 x double>* byval align 8, <1 x double>* byval
align 8) nounwind uwtable ssp {
entry:
  %x = load <1 x double>* %0, align 8
  %y = load <1 x double>* %1, align 8
  %add = fadd <1 x double> %x, %y
  ret <1 x double> %add
}

----

Looks like the only one that is ``correct'' is the double add.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.