pawosm-arm wrote:
> The bigger problem is that int->vector casts already have a different
> meaning. Compare:
>
> ```
> typedef int x __attribute((vector_size(8))); x f1(long long a) { return (x)a;
> }
> typedef int y __attribute((ext_vector_type(2))); y f2(long long a) { return
> (y)a; }
> ```
Ok, that says a lot:
```
; Function Attrs: mustprogress noinline nounwind optnone uwtable
define dso_local noundef <2 x i32> @_Z2f1x(i64 noundef %a) #0 {
entry:
%a.addr = alloca i64, align 8
store i64 %a, ptr %a.addr, align 8
%0 = load i64, ptr %a.addr, align 8
%1 = bitcast i64 %0 to <2 x i32>
ret <2 x i32> %1
}
; Function Attrs: mustprogress noinline nounwind optnone uwtable
define dso_local noundef <2 x i32> @_Z2f2x(i64 noundef %a) #0 {
entry:
%a.addr = alloca i64, align 8
store i64 %a, ptr %a.addr, align 8
%0 = load i64, ptr %a.addr, align 8
%conv = trunc i64 %0 to i32
%splat.splatinsert = insertelement <2 x i32> poison, i32 %conv, i64 0
%splat.splat = shufflevector <2 x i32> %splat.splatinsert, <2 x i32> poison,
<2 x i32> zeroinitializer
ret <2 x i32> %splat.splat
}
```
I wonder what was the point in creating two different meanings for the same
operation. I suspect the `ext_vector_type` supporters had also found that
adding a new builtin did require an enormous amount of hassle, so they've
decided to 'redefine' an existing operation for it.
https://github.com/llvm/llvm-project/pull/205432
_______________________________________________
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
