https://gcc.gnu.org/bugzilla/show_bug.cgi?id=125816
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Keywords| |easyhack
--- Comment #3 from Richard Biener <rguenth at gcc dot gnu.org> ---
Gemini:
Root Cause Analysis
When the vectorizer creates a vector constructor (e.g. _9 = {a_3(D), b_7(D)})
on a target/configuration where the corresponding vector mode (e.g. V2SImode
on x86_64 with `-mno-sse`) is **not** supported by hardware registers, the
RTL
expander (`expand_constructor in gcc/gcc/expr.cc) defaults to allocating a
temporary memory stack slot via assign_temp` and storing the constructor
elements piecemeal into it using memory writes.
However, because the mode's size is equal to a scalar integer mode (e.g.
DImode for 64-bit), we can construct the value directly in a scalar integer
register using shifts and bitwise operations. The helper store_constructor is
already fully capable of handling a register of scalar integer mode as its
target and automatically generates optimal shift/OR sequences for its
elements.
Proposed Fix
We will intercept vector constructor expansion in expand_constructor when:
1. The target does not support the vector mode natively in hardware
(!targetm.vector_mode_supported_p (mode)).
2. There exists a scalar integer mode of the same size (int_mode_for_mode
(mode).exists (&imode)).
3. We are not expanding stack parameters (modifier != EXPAND_STACK_PARM).
In this case, we allocate a pseudo register of the scalar integer mode, build
the value within it using store_constructor, and convert the result back to
the expected vector mode using force_lowpart_subreg.
====
I think the vector type should already have DImode, but this should be
verified, it might have V2SImode but not supported as Gemini suggests.
