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.
Pushed to the trunk.
commit d61efa3cd3378be38738bfb5139925d1505c1325
Author: Jeff Law <jeffreya...@gmail.com>
Date: Thu Aug 3 10:57:23 2023 -0400
[committed][RISC-V] Remove errant hunk of code
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.
Pushed to the trunk.
gcc/
* config/riscv/riscv.cc (riscv_rtx_costs): Remove errant hunk from
recent commit.
diff --git a/gcc/config/riscv/riscv.cc b/gcc/config/riscv/riscv.cc
index 9e75450aa97..d8fab68dbb4 100644
--- a/gcc/config/riscv/riscv.cc
+++ b/gcc/config/riscv/riscv.cc
@@ -2913,16 +2913,6 @@ riscv_rtx_costs (rtx x, machine_mode mode, int
outer_code, int opno ATTRIBUTE_UN
}
return false;
- case SET:
- /* A simple SET with a register destination takes its cost solely from
- the SET_SRC operand. */
- if (outer_code == INSN && REG_P (SET_DEST (x)))
- {
- *total = riscv_rtx_costs (SET_SRC (x), mode, SET, opno, total, speed);
- return true;
- }
- return false;
-
default:
return false;
}
