On 8/10/23 21:45, Palmer Dabbelt wrote:
OK, that seems like the way to go. I still think it's likely we'll need
to split up these types more, but that's something we can only deal with
when there's HW that behaves oddly.
Yea, but I think we can fault this in as problematic hardware arrives.
No, it's really a target issue. And what I was suggesting is that we
get to the point where we can enable the currently #if 0'd assert so
that if we introduce insns without an associated type, we get a nice
early warning. I wasn't up for tackling that this week ;-)
I was thinking of some sort of "TARGET_ALLOWS_UNKNOWN_INSNS" hook, but
poking around the uses that might not be meaningfully simpler than just
rejecting these in the backend -- certainly simpler if we're just
worried about RISC-V ;)
Not all ports have types at all. Some use types for things other than
scheduling. It'd be a huge can of worms.
This seems pretty mechinacial: just scrub through our MDs to check for
any un-typed insns, then add the assert and fix the failures. You're
more than welcome to have at it, but LMK if you want me to try and find
some time for someone to do it -- certainly seems like a good way for
someone new to dig in a bit.
Yes, definitely mechanical. And yes, it's a good way for someone to
start to get familiar with these bits -- I used the lack of types on
some of the bitmanip insns to help ramp up Raphael and one of the RAU
guys in this space.
Jeff
