diff options
author | Richard Biener <rguenther@suse.de> | 2022-02-11 11:08:57 +0100 |
---|---|---|
committer | Richard Biener <rguenther@suse.de> | 2022-02-14 09:12:36 +0100 |
commit | 3f10e0d50b5e3b3f64bc9a1a29177518d5f4468d (patch) | |
tree | 28d86c6cd026c600944044af4626dce34f18617c /gcc/c-family | |
parent | 0d31c8ec3fd9d1e8a16cac8605c862fbede07d46 (diff) | |
download | gcc-3f10e0d50b5e3b3f64bc9a1a29177518d5f4468d.zip gcc-3f10e0d50b5e3b3f64bc9a1a29177518d5f4468d.tar.gz gcc-3f10e0d50b5e3b3f64bc9a1a29177518d5f4468d.tar.bz2 |
middle-end/104497 - gimplification of vector indexing
The following attempts to address gimplification of
... = VIEW_CONVERT_EXPR<int[4]>((i & 1) != 0 ? inv : src)[i];
which is problematic since gimplifying the base object
? inv : src produces a register temporary but GIMPLE does not
really support a register as a base for an ARRAY_REF (even
though that's not strictly validated it seems as can be seen
at -O0). Interestingly the C++ frontend avoids this issue
by emitting the following GENERIC instead:
... = (i & 1) != 0 ? VIEW_CONVERT_EXPR<int[4]>(inv)[i] : VIEW_CONVERT_EXPR<int[4]>(src)[i];
The proposed patch below fixes things up when using an rvalue
as the base is OK by emitting a copy from a register base to a
non-register one. The ?: as lvalue extension seems to be gone
for C, C++ again unwraps the COND_EXPR in that case.
2022-02-11 Richard Biener <rguenther@suse.de>
PR middle-end/104497
* gimplify.cc (gimplify_compound_lval): Make sure the
base is a non-register if needed and possible.
* c-c++-common/torture/pr104497.c: New testcase.
Diffstat (limited to 'gcc/c-family')
0 files changed, 0 insertions, 0 deletions