Re: [RFC] ifcvt: Account for parallelism when costing noce sequences

On 8/12/2026 4:13 PM, Maxim Kuvyrkov wrote:
>> You first need to check that targetm.sched.issue_rate is non-null.
>> I wonder if the schedule issue_rate is too coarse. The midend also uses reassociation width as an estimate of CPU parallelism. On aarch64 at least we describe different widths for int, fp, and vector reassociation.
>> Have you considered using that hook instead?

I think we can settle on this once we're happy with the basics -- after 
all this is primarily just determining the divisor for the cost computation.

Ultimately we're looking at a proxy for how how many insns can issue per 
cycle, but without running the scheduler.  No number is going to be 
perfect.  To really make use of the additional flexibility reassociation 
width gives us we'd have to start to classify instructions based on what 
unit they're going to use.  Certainly do-able, though it adds 
complexity.  On the other hand some ports throttle issue_rate prior to 
register allocation to discourage over-eager scheduling, so we need to 
be cognizant of that as well. Again, no number will be perfect here, it 
just has to be a good approximation in the common case.

Jeff