https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111751
--- Comment #10 from rguenther at suse dot de <rguenther at suse dot de> --- On Tue, 10 Oct 2023, juzhe.zhong at rivai dot ai wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111751 > > --- Comment #9 from JuzheZhong <juzhe.zhong at rivai dot ai> --- > (In reply to Richard Biener from comment #8) > > ic = "\x00\x03\x06\t\f\x0f\x12\x15\x18\x1b\x1e!$\'*-"; > > ib = "\x00\x03\x06\t\f\x0f\x12\x15\x18\x1b\x1e!$\'*-"; > > vect__1.7_10 = MEM <vector(16) char> [(char *)&ib]; > > vect__2.10_34 = MEM <vector(16) char> [(char *)&ic]; > > > > so these. The lookup result is a STRING_CST object. I'm testing a patch. > > I have compare and debug between ARM SVE and RVV. > It seems that ARM SVE produce result of visit_reference_op_load is > CONST_VECTOR: > > (gdb) p debug(to) > { 0, 3, 6, 9, 12, 15, 18, 21, 24, 27, 30, 33, 36, 39, 42, 45 } > (gdb) p to->typed.type->type_common.mode > $23 = E_V16QImode > > However, RVV produce result of visit_reference_op_load is STRING_CST: > > (gdb) p debug (result) > "\x00\x03\x06\t\f\x0f\x12\x15\x18\x1b\x1e!$\'*-" > > This is the BLKmode. > > Could you tell me where I should fix in RISC-V backend? > It seems that it is not middle-end issue. The IL into the SVE case is likely different. The difference is wheher we have a direct hashtable hit for the load or whether we need to go through vn_reference_lookup_3 which will perform the type punning on its own.
