https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100866
--- Comment #5 from luoxhu at gcc dot gnu.org ---
(In reply to Segher Boessenkool from comment #4)
> This PR is specifically about the vec_revb builtin. But yes, we should
> look at what is generated for all other code (having only the builtin
> generate good code is suboptimal for a generic thing like this), and for
> other sizes as well.
Sorry I don't quite understand what you mean. IMO vec_revb is expanded by
CODE_FOR_revb_v8hi through revb_<mode> pattern. So this is where we should
change to make better code generation...
For V8HI, it is natural to use vspltish 8+vrlh to turn
{0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15} to
{1,0,3,2,5,4,7,6,9,8,11,10,13,12,15,14}.
But for V4SI, we need use vspltish+vrlh to turn it to
{1,0,3,2,5,4,7,6,9,8,11,10,13,12,15,14} first, and a "vrlw 16" to turn it to
{3,2,1,0,7,6,5,4,11,10,9,8,15,14,13,12}. I am not sure whether this is better
than lvx+xxlnor+vperm especially for V2DI&V1TI with additional "vrld 32" or
"vrld 32"+"vrlq 64"? (Those are all operations on register without load from
memory like lvx.)
bt 5
#0 gen_revb_v8hi (operand0=0x7ffff4d4ce40, operand1=0x7ffff4d4cf60) at
../../gcc/gcc/config/rs6000/vsx.md:5858
#1 0x0000000010b05360 in insn_gen_fn::operator()<rtx_def*, rtx_def*>
(this=0x130ab188 <insn_data+163016>) at../../gcc/gcc/recog.h:407
#2 0x0000000011aa1e30 in rs6000_expand_unop_builtin (icode=CODE_FOR_revb_v8hi,
exp=<call_expr 0x7ffff4f509a0>
, target=0x7ffff4d4ce40) at ../../gcc/gcc/config/rs6000/rs6000-call.c:9451
#3 0x0000000011ab27a4 in rs6000_expand_builtin (exp=<call_expr
0x7ffff4f509a0>, target=0x7ffff4d4ce40, subtarget=0x0, mode=E_V8HImode,
ignore=0) at ../../gcc/gcc/config/rs6000/rs6000-call.c:13157
#4 0x0000000010815268 in expand_builtin (exp=<call_expr 0x7ffff4f509a0>,
target=0x7ffff4d4ce40, subtarget=0x0, mode=E_V8HImode, ignore=0) at
../../gcc/gcc/builtins.c:9559
