On 4/18/25 9:28 AM, Li, Pan2 wrote:
Thanks Jeff for comments.
So we've got 3 patches all touching on the same basic area, so we need
to be careful about staging in.
Agree, thanks Jeff for paying attention.
So don't be surprised if most review time is focused on how the costing
model works since that's a common theme across these patches.
I see, Robin also mentioned this last year.
This feels very much like a hack to me. Why not just handle
VEC_DUPLICATE like the rest of the opcodes in riscv_rtx_costs?
Ultimately all that code needs to work together rather than having
separate paths for vector/scalar.
The idea is to separate vector related code into another sub function
for readability, instead of unroll the vector cost logic in riscv_rtx_costs.
Given the
riscv_rtx_costs function body is quite long already. Currently we may have
Vec_dup but it may introduce more cases.
All true and understandable. The problem is rtx_cost isn't really
separable like that. RTL in there can be fairly arbitrary and mixed,
just because we have a vector mode doesn't mean we won't have scalar
ops. Worse yet those scalar ops might be something more complex than a
simple register.
You should expect to get arbitrary RTL in there with arbitrary operands
-- it doesn't have to match anything actually supported by the target.
The point is the separation isn't neat and clean in rtx_costs. We've
kind of let it go as-is with the vector short-cut out, but I don't think
that's really where we want to be, it was just an expedient decision to
allow us to focus on more important stuff. Now that we're looking at
using rtx costing in more meaningful ways we probably need to rethink
the hack we've got in place.
Jeff
