[Bug tree-optimization/105668] [13 Regression] ICE: in gimple_expand_vec_cond_expr, at gimple-isel.cc:281 with -O -ftracer -fno-tree-fre since r13-458-gd75d4293dcc029a7

[rguenther at suse dot de]

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

--- Comment #4 from rguenther at suse dot de <rguenther at suse dot de> ---
On Fri, 20 May 2022, roger at nextmovesoftware dot com wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105668
> 
> Roger Sayle <roger at nextmovesoftware dot com> changed:
> 
>            What    |Removed                     |Added
> ----------------------------------------------------------------------------
>                  CC|                            |roger at nextmovesoftware dot com
> 
> --- Comment #3 from Roger Sayle <roger at nextmovesoftware dot com> ---
> I suspect that the middle-end could be a bit more forgiving whilst expanding
> vcond_mask.  If a target doesn't provide V1TImode, GCC can fall back to using
> V2DImode, and if that isn't supported V4SImode, then V8HImode then V16QImode.
> On x86-64, these all use the same vblendvb instruction or pand,pandn,por logic
> (also known as V128BImode :-).

That assumes that selecting V4SImode is the same as selecting 
from V2DImode, that is, vcond works on the "bitlevel" and V4SI and V2DI
"naturally overlap" in a vector register (and they can be aliased).
I'm not sure that's something we generally assume in GCC.  IIRC with
RISC-V for example that would not be the case since they represent
vectors in a way to have V4{QI,HI,SI} with zero-extended lanes.

I'm not sure how RISC-V represents this to the middle-end and how
the middle-end could distinguish those cases.  (looks like none
of it is on trunk?)