https://gcc.gnu.org/bugzilla/show_bug.cgi?id=127773
--- Comment #13 from Hongtao Liu <liuhongt at gcc dot gnu.org> --- (In reply to Michiel van Slobbe from comment #12) > Thanks for the patch, Hongtao, and for checking it against simdutf. > > I looked a bit further and I think I found one case that the patch doesn't > handle yet: validate_utf8_with_counts, when the input is at least 129 bytes > long and the error is roughly in bytes 63–126. On releases/gcc-16 with your > patch at -O2, that call still takes about 220 ns and 2 SSE/AVX assists, the > same as without the patch. With 128 bytes it drops to about 37 ns and 0 > assists. The repro is attachment 65822 [details]. It doesn't show up at -O3, > where the code is laid out differently. It also doesn't show up with current > trunk, which compiles simdutf's scalar tail routines without SSE. The issue is hidden after r17-4622-gbbf9808d787eac, and it can be exposed with -fno-vect-cost-model. > > The cause seems to be a 128-bit value that stays live in an XMM register > across the call. With IPA-RA that register counts as preserved, so the > vzeroupper goes after the call, even though it would be safe before it. > Attachment 65823 [details] is a smaller testcase that doesn't need simdutf. LIVE is HARD_REG_SET without any mode information, we don't konw if it's xmm live through call_insn or ymm live through call_insn, for the former it's safe to insert vzeroupper, for the later it's not. DATA_FLOW analysis needs to be done to get accurate width info, not sure if it worths.
