On Thu, Oct 3, 2024 at 3:15 AM Andrew Waterman <and...@sifive.com> wrote: > > On Wed, Oct 2, 2024 at 4:41 PM Jeff Law <jeffreya...@gmail.com> wrote: > > > > > > > > On 10/2/24 4:39 PM, Andrew Waterman wrote: > > > On Wed, Oct 2, 2024 at 5:56 AM Jeff Law <jeffreya...@gmail.com> wrote: > > >> > > >> > > >> > > >> On 9/5/24 12:52 PM, Palmer Dabbelt wrote: > > >>> We have cheap logical ops, so let's just move this back to the default > > >>> to take advantage of the standard branch/op hueristics. > > >>> > > >>> gcc/ChangeLog: > > >>> > > >>> PR target/116615 > > >>> * config/riscv/riscv.h (LOGICAL_OP_NON_SHORT_CIRCUIT): Remove. > > >> So on the BPI this is a pretty clear win. Not surprisingly perlbench > > >> and gcc are the big winners. It somewhat surprisingly regresses x264, > > >> deepsjeng & leela, but the magnitudes are smaller. The net from a cycle > > >> perspective is 2.4%. Every benchmark looks better from a branch count > > >> perspective. > > >> > > >> So in my mind it's just a matter of fixing any testsuite fallout (I > > >> would expect some) and this is OK. > > > > > > Jeff, were you able to measure the change in static code size, too? > > > These results are very encouraging, but I'd like to make sure we don't > > > need to retain the current behavior when optimizing for size. > > Codesize is ever so slightly worse. As in less than .1%. Not worth it > > in my mind to do something different in that range.
It probably helps code-size when not optimizing for size depending on how you align jumps. Richard. > Thanks. Agreed. > > > > > Jeff
