Hi Alexander!
在 2026/5/1 17:45, Alexander Monakov 写道:
> On Fri, 1 May 2026, Kewen Lin wrote:
>
>>> I strongly suspect a part of it is improper divider unit modeling that was
>>> fixed
>>> for other pipeline models in context of bug 87832. In particular, I see
>>>
>>> +;; IDIV
>>> +(define_insn_reservation "c86_4g_m7_idiv_DI" 41
>>> + (and (eq_attr "cpu" "c86_4g_m7")
>>> + (and (eq_attr "type" "idiv")
>>> + (and (eq_attr "mode" "DI")
>>> + (eq_attr "memory" "none"))))
>>> + "c86-4g-m7-double,c86-4g-m7-ieu3*41")
>>>
>>> and ieu3 appears to be an ALU used for other instructions, not the divider.
>>> This
>>> likely blows up the automaton, and doesn't properly model the pipeline
>>> anyway.
>>>
>>> Kewen, please have a look at the patches linked from PR 87832, they all have
>>> commit messages, and the strategy is not complicated (create a separate
>>> cpu_unit
>>> for the partially-pipelined divider, use it in reservations, use
>>> throughput, not
>>> latency figures ('*41' above is wrong): https://gcc.gnu.org/pr87832
>>
>> I went through the commits and made a draft patch as the bottom by
>> following commit r13-4956-gec1db9017939bb for not pipelined division.
>> It did make the compilation time issue gone, and it turned out the
>> division etc. modeling caused a combinatorial explosion in the automaton
>> as you suspected, see the details below:
>>
> [snip]
>>
>> I have a question on this solution with "fpu*N -> fpu,divider*N",
>> IIUC, the former means the insn occupies fpu for N cycles while
>> the later means it occupies fpu for 1 cycle and then divider for
>> N cycles. From what I got from our hardware team colleages
>> months ago, I think the former matches our hardware behavior
>> better, we want scheduling to consider fpu unavailable for N cycles.
>> From this perspective, does it mean this kind of adjustment is actually
>> a trade-off between exact modeling and automaton explosion?
>
> Ah, that is unexpected to me. My understanding is that Hygon microarchitecture
> is derived from first-generation AMD Zen, and Andreas Abel measured
> floating-point division latency/throughput as 10c/3c for DIVSS instruction,
> indicating that it is partially pipelined:
> https://uops.info/html-instr/DIVSS_XMM_XMM.html#ZEN+
Sorry for getting back to you late, we spent some time discussing with
hardware team meanwhile making some experiments to confirm back and forth.
> Hygon microarchitecture is derived from first-generation AMD Zen.
AFAIK, floating point and cryptography related supports weren't derived from
first-generation AMD Zen, so floating point part is different.
>
> (I misunderstood his measurements for the integer division though, it is not
> pipelined on Zen, invalidating my claim above regarding '*41' being wrong;
> but, at least on Zen2, it doesn't occupy a generic ALU for all N cycles)
Thanks for the clarification. Yes, our testing demonstrated integer division
does not occupy a generic ALU for all N cycles long, which can be available
next cycle at best case. c86-4g-m7 makes great improvement on integer
division to reduce the latency, though it's still not pipelined, we will fix the
related modeling soon.
>
> His measurements also show that AMD PMU accounts only one uop for the FP3 pipe
> per one DIVSS, indicating that FP3 may be available for other instructions. I
> do
> not have access to a first-generation Zen, but I can confirm that on Zen2 by
> running the following experiment:
>
> .intel_syntax noprefix
> .globl _start
> _start:
> mov ecx, 1000000
> vmovss xmm1, one
> .p2align 5
> .loop:
> vdivss xmm2, xmm1, xmm1
> vdivss xmm2, xmm1, xmm1
> .rept 25
> vorps xmm2, xmm1, xmm1
> .endr
>
> dec ecx
> jnz .loop
> ud2
> one:
> .long 0x3f800000
>
> This loop runs at 7 cycles per iteration, so on four cycles the pipe that
> runs DIVSS also accepts ORPS. Similarly, if I change ORPS to CVTSS2SD, which
> only runs on FP3, I see that with '.rept 4' the loop still runs at 7 cycles
> per iteration.
Thanks for the detailed explanation and examples. This loop on c86-4g-m4
runs 18+ cycles per iteration, it's close to 10c what we modeled for per DIVSS.
since the total cycles for each iteration changed, I adjusted the number for
ORPS, the iteration cycle starts to increase with number 56, becomes 19+c
after number 59. If leaving only one vdivss in the loop, the cycle per
iteration
is 9+c, the relationship between #ORPS and cycles per iteration:
27 9+
28 9+
29 9+
30 10+
It turns out that the FPU isn't fully blocked but it's unavailable for a while.
Considering the possible FE bandwidth impact and other constraints, I tried
vpslld which only runs on FP1, the result looks better:
#VPSLLD vs. #cycles per iteration
6 9+
7 10+
It looks FP1 can be available for about 6 cycles at best.
>
> (on Zen1 the two divisions would take 6 cycles, not 7, and .rept count
> would have to be adjusted)
>
> A similar experiment with loop latency-bound on divisions:
>
> .intel_syntax noprefix
> .globl _start
> _start:
> mov ecx, 1000000
> vmovss xmm1, one
> vxorps xmm0, xmm0, xmm0
> .p2align 5
> .loop:
> vdivss xmm1, xmm1, xmm1
> vdivss xmm1, xmm1, xmm1
> .rept 74
> vorps xmm2, xmm0, xmm0
> .endr
>
> dec ecx
> jnz .loop
> ud2
> one:
> .long 0x3f800000
>
> runs at 20 cycles per iteration on Zen2, and there are 14 cycles when FP3
> handles ORPS while DIVSS is in progress.
Running this case on c86-4g-m4, it takes 24+c per iteration without any
adjustment,
and #ORPS 60 takes 22c+ while 56 takes 20c. Without any ORPS, it takes 20c as
well. Considering the previous different behaviors between ORPS and VPSLLD, I
tried with VPSLLD and it showed about ~12c when FP1 handles VPSLLD while
DIVSS is in progress. Both testings showed that FPx is just unavailable for
some
cycles.
If we consider the best case that FP pipe is only unavailable for first T1 and
last T2,
do you think we should adjust the modeling to something like:
fpu,divider*N -> (fpu+divider)*T1, divider*(N-T1-T2), (fpu+divider)*T2
Or such modeling can increase the complexity and lead to automaton explosion,
at the same time the benefits may not be significant on modern machines, we can
just aggressively ignore the difference.
BR,
Kewen
>
> If this is not the case on Hygon and floating-point division actually makes
> an FP pipe completely unavailable for other instructions, then yes, the
> adjustment done by the patch would not describe the hardware accurately.
>
> Alexander
