[Bug target/105930] [12/13 Regression] Excessive stack spill generation on 32-bit x86
Mon Jun 13 17:39:49 GMT 2022
--- Comment #12 from Linus Torvalds <email@example.com> ---
(In reply to Jakub Jelinek from comment #11)
> Anyway, I think we need to understand what makes it spill that much more,
> and unfortunately the testcase is too large to find that out easily, I think
> we should investigate commenting out some rounds.
I think you can comment out all the rounds except for one, and still see the
effects of this.
At least when I try it on godbolt with just ROUND(0) in place and rounds 1-12
deleted, for gcc-11.3 I get a stack frame of 388.
And with gcc-12.1 I get a stack frame of 516. Obviously that's not nearly as
huge, but it's still a fairly significant expansion and is presumably due to
the same basic issue.
I used godbolt just because I no longer have 11.3 installed to compare against,
so it was the easiest way to verify that the stack expansion is still there.
Just to clarify: that's still with
-O2 -m32 -mno-sse -mno-mmx -mno-sse2 -mno-3dnow -mno-avx
I'm sure it depends on the flags.
The code is still not exactly trivial with just one round in place. It's a
cryptographic hash, after all. But when compiling for 64-bit mode it all looks
fairly straightforward, it really is that DImode stuff that makes it really
ungainly when using -m32.
More information about the Gcc-bugs