Wilco Dijkstra <wilco.dijks...@arm.com> writes: > Testing shows the setting of 32:16 for jump alignment has a significant > codesize > cost, however it doesn't make a difference in performance. So set jump-align > to 4 to get 1.6% codesize improvement.
I was leaving this to others in case it was obvious to them. On the basis that silence suggests it wasn't, :-) could you go into more details? Is it expected on first principles that jump alignment doesn't matter for Neoverse N1, or is this purely based on experimentation? If it's expected, are we sure that the other "32:16" entries are still worthwhile? When you say it doesn't make a difference in performance, does that mean that no individual test's performance changed significantly, or just that the aggregate score didn't? Did you experiment with anything inbetween the current 32:16 and 4, such as 32:8 or even 32:4? The problem with applying the patch only with the explanation above is that if someone in future has evidence that jump alignment can make a difference for their testcase, it would be very hard for them to reproduce the reasoning that led to this change. Thanks, Richard > OK for commit? > > ChangeLog > 2019-12-24 Wilco Dijkstra <wdijk...@arm.com> > > * config/aarch64/aarch64.c (neoversen1_tunings): Set jump_align to 4. > > -- > diff --git a/gcc/config/aarch64/aarch64.c b/gcc/config/aarch64/aarch64.c > index > 1646ed1d9a3de8ee2f0abff385a1ea145e234475..209ed8ebbe81104d9d8cff0df31946ab7704fb33 > 100644 > --- a/gcc/config/aarch64/aarch64.c > +++ b/gcc/config/aarch64/aarch64.c > @@ -1132,7 +1132,7 @@ static const struct tune_params neoversen1_tunings = > 3, /* issue_rate */ > (AARCH64_FUSE_AES_AESMC | AARCH64_FUSE_CMP_BRANCH), /* fusible_ops */ > "32:16",/* function_align. */ > - "32:16",/* jump_align. */ > + "4",/* jump_align. */ > "32:16",/* loop_align. */ > 2,/* int_reassoc_width. */ > 4,/* fp_reassoc_width. */
