目前的patch代码还有一些问题，要把下面说的有问题的部分先撤销了：
[PATCH v2] i386: Support HYGON c86-4g series processors
Alexander Monakov
Thu Apr 30 07:42:09 GMT 2026
Previous message (by thread): [PATCH v2] i386: Support HYGON c86-4g series processors
Next message (by thread): [PATCH v2] i386: Support HYGON c86-4g series processors
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
On Thu, 30 Apr 2026, Richard Biener wrote:
> On Thu, Apr 30, 2026 at 4:10 AM Kewen Lin wrote:
> >
> > Hi Rainer & H.J.,
> >
> > 在 2026/4/30 6:31, H.J. Lu 写道:
> > > On Thu, Apr 30, 2026 at 5:24 AM Rainer Orth wrote:
> > >> between yesterday and today, I saw an increase in bootstrap times
> > >> between 37 and 75%:
> > >>
> > >> * i686-pc-linux-gnu, -j128 1:03:03 -> 1:50:00
> > >>
> > >> * i386-pc-solaris2.11, -j28 3:08:11.19 -> 4:18:22.77
> > >>
> > >> while the x86_64-pc-linux-gnu times are virtually unchanged. It seems
> > >> likely that this patch is the culprit. Is anyone else seeing the same?
> > >>
> > >
> > > Yes, I have seen a similar compile time increase on Linux/i686.
> >
> > Thanks for the information, we didn't test for i686 before, are trying to
> > reproduce this locally first. Did you happen to notice which part inceased
> > much or any suspicious point like automation gen etc.?
>
> genautomata now takes ages for me.
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): gcc dot gnu dot org/pr87832
Alexander
--
修改:azuresea FROM 117.67.165.*
FROM 117.67.165.*