https://gcc.gnu.org/bugzilla/show_bug.cgi?id=127246
--- Comment #2 from ktkachov at gcc dot gnu.org ---
(In reply to Drea Pinski from comment #1)
> So we end up with:
> ```
> <bb 4> [local count: 1073741764]:
> # next_instr_78 = PHI <next_instr_73(24), next_instr_219(3),
> next_instr_210(6), next_instr_201(7), next_instr_193(8), next_instr_185(9),
> next_instr_177(10), next_instr_169(11), next_instr_161(12),
> next_instr_153(13), next_instr_145(14), next_instr_137(15),
> next_instr_129(16), next_instr_121(17), next_instr_113(18),
> next_instr_106(19), next_instr_100(20), next_instr_93(21),
> next_instr_87(22), next_instr_80(23)>
> # stack_pointer_225 = PHI <_238(24), stack_pointer_224(3), _238(6),
> stack_pointer_206(7), _238(8), stack_pointer_190(9), _238(10),
> stack_pointer_174(11), _238(12), stack_pointer_158(13), _238(14),
> stack_pointer_142(15), _238(16), stack_pointer_126(17), _238(18),
> stack_pointer_111(19), _238(20), stack_pointer_98(21), _238(22),
> stack_pointer_85(23)>
> # gotovar.0_216 = PHI <_63(24), _6(3), _9(6), _12(7), _15(8), _18(9),
> _21(10), _24(11), _27(12), _30(13), _33(14), _36(15), _39(16), _42(17),
> _45(18), _48(19), _51(20), _54(21), _57(22), _60(23)>
> _227 = (long unsigned int) stack_pointer_225;
> _228 = (long unsigned int) next_instr_78;
> _229 = {_228, _227};
>
> <bb 5> [local count: 1073741824]:
> # gotovar.0_66 = PHI <gotovar.0_216(4), _3(2)>
> # vect_next_instr_64.7_234 = PHI <_229(4), vect_next_instr_70.6_231(2)>
> _237 = BIT_FIELD_REF <vect_next_instr_64.7_234, 64, 64>;
> _238 = (long int *) _237;
> _235 = BIT_FIELD_REF <vect_next_instr_64.7_234, 64, 0>;
> _236 = (const short unsigned int *) _235;
> goto gotovar.0_66;
> ```
>
> Notice how there is an extra bb4 which most locations goto except for the
> entry block.
>
> This seems more on accident and how fragile `computed goto unfactoring`
> requires just one bb to do the unfactoring.
That's true and I've hacked around and got it to unfactor anyway (I'll polish
the patches in due time), but even when it is unfactored the result is 2%
slower than without the vectorisation. So I think vectorisation costs still
need to somehow catch it.
