Attention is currently required from: Elyes Haouas, Felix Singer, Lennart Eichhorn.
Julius Werner has posted comments on this change. ( https://review.coreboot.org/c/coreboot/+/70771?usp=email )
Change subject: crossgcc: Upgrade GCC from 11.4.0 to 13.2.0 ......................................................................
Patch Set 27:
(1 comment)
Patchset:
PS27:
Julius, can you help on this issue? https://qa.coreboot. […]
Strangely enough, when I check out this patch and rebuild crossgcc, I do see an increase in size compared to the old compiler, but it still fits into 100K for me. Is there a reason I would get different results with the same compiler and same code?
Anyway, I dug into the reason for the size difference a little and identified a number of situations where the new GCC generates larger code (but also some where it's better). One example is that it doesn't seem to be as eager to produce separate jump tables for small-ish switch statements (easy to see in vb2_digest_extend()) — maybe that's some sort of branch predictor optimization so that might be an intended trade-off. I've also found one situation about accessing multiple indices in a global array that just seems to be a clear bug (easy to see in vboot's default vb2ex_hwcrypto_digest_finalize()), I filed that at https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112573. There is also a big difference in LzmaDecode() which becomes over 1KB larger (~20% increase), but that code is a horrible mess even in source form so I'm afraid there's probably not much we can understand there.
In general, it would probably be a good idea to just always compare binary sizes during compiler uprevs (at least one board for each architecture) and record the findings in the commit message, so that we're at least aware of big changes and can try to investigate if necessary.
Anyway, this should fix the Trogdor issue: CB:79074
-
Julius Werner (Code Review)