[Bug middle-end/101876] New: [290x] vector builtin vec_permi fails to resolve with #pragma GCC target

[Bug middle-end/101876] New: [290x] vector builtin vec_permi fails to resolve with #pragma GCC target

[mhillen at linux dot ibm.com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101876

            Bug ID: 101876
           Summary: [290x] vector builtin vec_permi fails to resolve with
                    #pragma GCC target
           Product: gcc
           Version: 12.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: middle-end
          Assignee: unassigned at gcc dot gnu.org
          Reporter: mhillen at linux dot ibm.com
  Target Milestone: ---

When using #pragma GCC target("arch=z13,vx") to enable vectorization extensions
on s390x, __builtin_s390_vec_permi fails to resolve.


Example code:
#pragma GCC target("arch=z13,vx")

#include <vecintrin.h>

typedef unsigned long long v2di __attribute__((vector_size(16)));

v2di foo(char *ptr) {
    v2di v = *(v2di *)ptr;
    v = vec_permi(v, v, 0);
    return v;
}

Fails when compiled with gcc -c -march=zEC12, but compiles as expected with gcc
-march=z13

[Bug middle-end/101876] [290x] vector builtin vec_permi fails to resolve with #pragma GCC target

[mhillen at linux dot ibm.com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101876

--- Comment #1 from Marius Hillenbrand <mhillen at linux dot ibm.com> ---
Comparing results with -mdebug, the variant that should match is ignored

with -march=z13:

...
s390_resolve_overloaded_builtin, code =  606, __builtin_s390_vec_permi - 
overloaded
checking variant number: 187 mismatch in operand: 1 incoming: v2di expected:
vector(2) long long int
checking variant number: 188 mismatch in operand: 1 incoming: v2di expected:
vector(2) long long unsigned int
checking variant number: 189 perfect match score: 0
...

with -march=zEC12:
...
s390_resolve_overloaded_builtin, code =  606, __builtin_s390_vec_permi - 
overloaded
checking variant number: 187 mismatch in operand: 1 incoming: v2di expected:
vector(2) long long int
checking variant number: 188 mismatch in operand: 1 incoming: v2di expected:
vector(2) long long unsigned int
checking variant number: 189 mismatch in operand: 1 incoming: v2di expected:
vector(2) long long unsigned int
checking variant number: 190 mismatch in operand: 1 incoming: v2di expected:
vector(2) double
In file included from tests/target-pragma-vector-builtins.c:13:
tests/target-pragma-vector-builtins.c: In function 'foo':
tests/target-pragma-vector-builtins.c:23:9: error: invalid parameter
combination for intrinsic '__builtin_s390_vec_permi'
   23 |     v = vec_permi(v, v, 0);
      |         ^~~~~~~~~
...

[Bug target/101876] [s390x] vector builtin vec_permi fails to resolve with #pragma GCC target

[mhillen at linux dot ibm.com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101876

--- Comment #2 from Marius Hillenbrand <mhillen at linux dot ibm.com> ---
Narrowed down what triggers the issue after experimenting with another example:
when the pragma sets 'vx' before the typedef, then the resulting type
definition appears broken. when enabling 'vx' only after the typedef, then the
example compiles successfully.

updated example:

#ifdef BROKEN
#pragma GCC target("arch=z13") // note: z13 implies vx
#else
#pragma GCC target("arch=z13,no-vx") // ... so turn off 'vx' again
#endif

#include <vecintrin.h>

typedef unsigned long long v2di __attribute__((vector_size(16)));

#ifndef BROKEN
#pragma GCC target("vx")
#endif

v2di foo(char *ptr) {
    v2di v = *(v2di *)ptr;
    v = vec_permi(v, v, 0);
    return v;
}

Compile fails
gcc -march=z10 -O3 -DBROKEN -c -S -o- example.c
but succeeds without -DBROKEN

[Bug target/101876] [s390x] vector builtin vec_permi fails to resolve with #pragma GCC target

[mhillen at linux dot ibm.com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101876

--- Comment #3 from Marius Hillenbrand <mhillen at linux dot ibm.com> ---
The issue is caused by inconsistent alignment of vector_types between the types
(a) expected or returned by builtin functions and (b) the typedef in the
example code. In the failing cases, there's a mismatch of 16-Byte and 8-Byte
(compliant with the ABI) alignment. In the successful cases, either both use
16-Byte or 8-Byte alignment.

When gcc starts, s390_init_builtins defines builtin functions with their
corresponding type information. That includes vector builtins. While creating
the builtin types for these builtins, when gcc starts with -march < z13, then
s390_vector_alignment defers to default_vector_alignment, which results in
natural alignment. That results in 16-Byte alignment of the 16-Byte vectors.
Once the pragma switched to an arch level with VX support (TARGET_VX and
TARGET_VX_ABI are true), then s390_vector_alignment selects 8-Byte alignment in
accordance with the vector ABI.

The C++ example (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101877) ICEs
because two structurally identical vector types have different canonical types
(as a result of the different alignment?!).

[Bug target/101876] [s390x] vector builtin vec_permi fails to resolve with #pragma GCC target

[mhillen at linux dot ibm.com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101876

--- Comment #4 from Marius Hillenbrand <mhillen at linux dot ibm.com> ---
*** Bug 101877 has been marked as a duplicate of this bug. ***

[Bug target/101876] [s390x] vector builtin vec_permi fails to resolve with #pragma GCC target

[mhillen at linux dot ibm.com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101876

--- Comment #5 from Marius Hillenbrand <mhillen at linux dot ibm.com> ---
The root cause is not the difference in alignment between vector types in
itself, but the resulting "confusion" in the type system when the #pragma GCC
target switches the default vector alignment.

It looks like we generally assume that the default vector alignment should be
invariant during a compile run. Failing that will break two other invariants
that then result in the s390-specific vector builtins to resolve or the C++
frontend to ICE.

Vector types with the same structure yet different alignments would usually end
up as type variants that link to the same TYPE_MAIN_VARIANT and TYPE_CANONICAL
because of how they are constructed by make_vector_type: (1) construct a
default variant of the vector type, (2) try to find the canonical object for
that type in the hash table or add the new type as such, (3) if required attach
the to-be-constructed type as a type variant to the canonical object. The hash
table lookup compares alignment. Thus, retrieving a previously created
canonical object in that process only works if the "default variant" in step
(1) has the same alignment as before.

When #pragma GCC target switches between non-VX and VX-enabled targets, we
break that invariant. pre-VX, vector alignment defaults to natural alignment.
with -mvx, vectors align to 8 Bytes. Consequently, make_vector_type will fail
to identify any existing "canonical objects" for vector types and add new ones
to the hash table -- possibly resulting in multiple clusters that represent the
same vector types.

For example, in 
typedef int v4si_raw __attribute__((vector_size(16))); // aligned to 16 B
typedef int v4si_raw_aligned8 __attribute__((vector_size(16), aligned(8)));

#pragma GCC target("arch=z13") // implies -mvx

typedef int v4si_z13 __attribute__((vector_size(16))); // aligned to 8 B
typedef int v4si_z13_aligned16 __attribute__((vector_size(16), aligned(16)));

The types v4si_z13 and v4si_z13_aligned16 will fail to be associated to v4si as
their main variant. Instead, these two will link to v4si_z13 as their main
variant.

The s390-specific vector builtins fail to resolve, because the code assumes
that structurally equivalant vector types would have the same
TYPE_MAIN_VARIANT. Similarly, the C++ frontend may hit the failing assertion
that structurally equivalent types should have the same TYPE_CANONICAL (for
vector types, that would point to the shared TYPE_MAIN_VARIANT).