https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117353
--- Comment #7 from Vineet Gupta <vineetg at gcc dot gnu.org> ---
(In reply to Jeffrey A. Law from comment #6)
> So my approach would be to note the insn number, then set a conditional
> breakpoint in make_insn_raw (after it initializes INSN_UID in the new
> insn). The condition would be insn->u2.insn_uid == <insn number> or
> something close to that.
Nice: I've been using the uid conditional breakpoints forever but bt out of
make_insn_raw () is a nice trick to know.
> That gives us a handle on precisely where it's created, then walk up the
> frames into the RISC-V code. As Robin noted, could easily be a missed
> can_create_pseudos_p test.
Yeah, as Robin said it is the const vect and reload move ....
lra_constraints
curr_insn_transform
lra_emit_move
emit_move_insn
gen_movv8qi
riscv_vector::legitimize_move (rtx dest, rtx *srcp)
if (CONST_VECTOR_P(src))
riscv_vector::expand_const_vector <---
expand_simple_binop
expand_binop
expand_binop_directly
emit_insn
make_insn_raw
In expand_const_vector() it seems we need to explicitly handle lra_in_progress
for this case, which seems non trivial to me personally.
However I have a different question about these vector shifts lacking a vsetvl
veneer due to being post/during reload. For the ones pre-existing before
reload, the splitter in autovec.md does the trick.
;; -------------------------------------------------------------------------
;; ---- [INT] Binary shifts by scalar.
;; -------------------------------------------------------------------------
;; Includes:
;; - vsll.vx/vsra.vx/vsrl.vx
;; - vsll.vi/vsra.vi/vsrl.vi
;; -------------------------------------------------------------------------
(define_insn_and_split "<optab><mode>3"
[(set (match_operand:V_VLSI 0 "register_operand" "=vr")
(any_shift:V_VLSI
(match_operand:V_VLSI 1 "register_operand" " vr")
(match_operand:<VEL> 2 "vector_scalar_shift_operand" " rK")))]
"TARGET_VECTOR && can_create_pseudo_p ()"
"#"
"&& 1"
[(const_int 0)]
{
operands[2] = gen_lowpart (Pmode, operands[2]);
riscv_vector::emit_vlmax_insn (code_for_pred_scalar (<CODE>, <MODE>mode),
riscv_vector::BINARY_OP, operands);
DONE;
}
I wonder if we can instead enhance it to use emit_vlmax_insn_lra() type
constructs if lra_in_progress ?
