Re: [PATCH] RISC-V: Handle no_insn in TARGET_SCHED_VARIABLE_ISSUE.

[Jeff Law <jeffreyalaw@gmail.com>]

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