On 8/3/23 11:41, Palmer Dabbelt wrote:
On Thu, 03 Aug 2023 08:05:09 PDT (-0700), gcc-patches@gcc.gnu.org wrote:
I'm using this hunk locally to more thoroughly exercise the zicond paths
due to inaccuracies elsewhere in the costing model. It was never
supposed to be part of the costing commit though. And as we've seen
it's causing problems with the vector bits.
While my testing isn't complete, this hunk was never supposed to be
pushed and it's causing problems. So I'm just ripping it out.
There's a bigger TODO in this space WRT a top-to-bottom evaluation of
the costing on RISC-V. I'm still formulating what that evaluation is
going to look like, so don't hold your breath waiting on it.
We touched on it a bit in the call a few days ago, but I definately
agree that's worth doing: the current cost and pipeline models are from
when the ISA was a lot simpler, it's changed a lot over the last few
years so we're likely to need a bunch of work here. At a bare minimum
there's some refactoring that could be done to make the code saner, it's
been through a few rounds of work so there's some cruft.
Our rough plan was to get together some microbenchmarks to drive the
model. We're using Microprobe for that, Patrick has been updating it to
support various new ISA extensions -- I think that's all upstream
already. That'll spit out throughput/latency tables that we can build
the pipeline/cost models on top of. The hope was to run these on some
extant systems so we could start answering questions like that
overlapping stores on the C906, but we haven't gotten around to that yet.
Everything past microprobe is just ideas right now. The cost/pipeline
model related issues on the scalar side look small so most of the worry
is on vector. The general theory is that we're going to need a lot of
work on vector codegen to get things going fast for us, but it's all
very microarchitecture specific. We're not aiming for any of this for
GCC 14.
So if you guys have time to look that'd be awesome, I don't think anyone
over here will conflict with it any time soon -- aside from whatever
falls out of bugs and the generic optimization work, but no way around
that sort of thing.
Right. I think we're probably tackling different issues.
The problem I'm looking at right now is when we ask for the cost of a
sequence of insns, the underlying costs we get per insn are not at all
in line with expectations. We have likely either failed to provide one
of the desired hook entries or we're missing toplevel constructs like
INSN & SET in our riscv_rtx_costs. I'm not sure which it is yet, but
there's clearly something wrong in there. IMHO it falls into the "fix
the stupid stuff" space.
The problem you're starting to chase sounds more like pipeline modeling
with perhaps a bit of riscv_rtx_costs work thrown in as well, but more
on the pipeline modeling side.
Jeff
