On 8/18/23 16:08, Jeff Law wrote:
There is some slight regression in code quality for a number of
vector tests where we spill more due to different instructions order.
The ones I looked at were a mix of bad luck and/or brittle tests.
Comparing the size of the generated assembly or the number of vsetvls
for SPECint also didn't show any immediate benefit but that's obviously
not a very fine-grained analysis.
Yea. In fact I wouldn't really expect significant changes other than
those key loops in x264.
Care to elaborate a bit more please. I've seen severe reg pressure /
spills in a bunch of others: cactu, lbm, exchange2. Is there something
specific to x264 spills ?
diff --git a/gcc/common/config/riscv/riscv-common.cc
b/gcc/common/config/riscv/riscv-common.cc
index 4737dcd44a1..59848b21162 100644
--- a/gcc/common/config/riscv/riscv-common.cc
+++ b/gcc/common/config/riscv/riscv-common.cc
@@ -2017,9 +2017,11 @@ static const struct default_options
riscv_option_optimization_table[] =
{
{ OPT_LEVELS_1_PLUS, OPT_fsection_anchors, NULL, 1 },
{ OPT_LEVELS_2_PLUS, OPT_free, NULL, 1 },
+ { OPT_LEVELS_1_PLUS, OPT_fsched_pressure, NULL, 1 },
Nit2: maybe move this 1 line up to keep LEVEL_1 together, at least the
new ones being added.
#if TARGET_DEFAULT_ASYNC_UNWIND_TABLES == 1
{ OPT_LEVELS_ALL, OPT_fasynchronous_unwind_tables, NULL, 1 },
{ OPT_LEVELS_ALL, OPT_funwind_tables, NULL, 1},
+ /* Enable -fsched-pressure by default when optimizing. */
#endif
{ OPT_LEVELS_NONE, 0, NULL, 0 }
};
Shouldn't the comment move up to before the OPT_fsched_pressure line?
Yep I had the exact same first though but then thought it was something
deeper.
Turned out to be Occam's Razor after all :-)
Thx,
-Vineet
