[Bug target/105930] [12/13 Regression] Excessive stack spill generation on 32-bit x86

torvalds@linux-foundation.org gcc-bugzilla@gcc.gnu.org
Mon Jun 13 17:39:49 GMT 2022


--- Comment #12 from Linus Torvalds <torvalds@linux-foundation.org> ---
(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 mailing list