# Patchwork [mips,testsuite] Fix gcc.target/mips/octeon-bbit-2.c for -Os

Submitter Steve Ellcey Oct. 8, 2012, 4:21 p.m. <9bd1abff-65e1-488e-ba9b-0e0ea8d90abe@EXCHHUB01.MIPS.com> mbox | patch /patch/190057/ New show

## Comments

Steve Ellcey - Oct. 8, 2012, 4:21 p.m.
The gcc.target/octeon-bbit-2.c is failing with -Os because that optimization
level does not do whichever optimization it is that results in a bbit instead
of a bbit[01]l.  I would like to skip this test for -Os the way it already gets
skipped for -O0.

Tested on mips-mti-elf.  Ok for checkin?

Steve Ellcey
sellcey@mips.com

2012-10-08  Steve Ellcey  <sellcey@mips.com>

* gcc.target/octeon-bbit-2.c: Skip for -Os optimization level.
Mike Stump - Oct. 8, 2012, 6:09 p.m.
On Oct 8, 2012, at 9:21 AM, Steve Ellcey <sellcey@mips.com> wrote:
> The gcc.target/octeon-bbit-2.c is failing with -Os because that optimization
> level does not do whichever optimization it is that results in a bbit instead
> of a bbit[01]l.  I would like to skip this test for -Os the way it already gets
> skipped for -O0.
>
> Tested on mips-mti-elf.  Ok for checkin?

Ideally I'd like a mips expert to weigh in on this.  The issue is, is the code smaller with the other instruction?  If so, is there a reasonable way to obtain that type of win more often in the port with -Os?  Now, if you are that mips expert, that's fine, but, trivially you don't need my approval to check it in.  If the code is larger, trivially, the patch is ok.  If the optimization generally hurt code size and can't be made to win, the patch is ok.  If always the same size, it would seem ok.   I just don't have the mips specific background to know which case this is.
Steve Ellcey - Oct. 8, 2012, 6:26 p.m.
On Mon, 2012-10-08 at 11:09 -0700, Mike Stump wrote:
> On Oct 8, 2012, at 9:21 AM, Steve Ellcey <sellcey@mips.com> wrote:
> > The gcc.target/octeon-bbit-2.c is failing with -Os because that optimization
> > level does not do whichever optimization it is that results in a bbit instead
> > of a bbit[01]l.  I would like to skip this test for -Os the way it already gets
> > skipped for -O0.
> >
> > Tested on mips-mti-elf.  Ok for checkin?
>
> Ideally I'd like a mips expert to weigh in on this.  The issue is, is the code smaller with the other instruction?
> If so, is there a reasonable way to obtain that type of win more often in the port with -Os?  Now, if you are that
> mips expert, that's fine, but, trivially you don't need my approval to check it in.  If the code is larger,
> trivially, the patch is ok.  If the optimization generally hurt code size and can't be made to win, the patch is ok.
> If always the same size, it would seem ok.   I just don't have the mips specific background to know which case this
> is.

Well, I checked -O1, -O2 and -Os.  The -Os code is smaller then -O1 but
larger then -O2.  I didn't dig deep enough to find out exactly which
optimization is causing the change in instruction usage.  Perhaps
Richard Sandiford will have an opinion on this change.

Steve Ellcey
sellcey@mips.com

## Patch

diff --git a/gcc/testsuite/gcc.target/mips/octeon-bbit-2.c b/gcc/testsuite/gcc.target/mips/octeon-bbit-2.c
index 9bd8dce..7d88d68 100644
--- a/gcc/testsuite/gcc.target/mips/octeon-bbit-2.c
+++ b/gcc/testsuite/gcc.target/mips/octeon-bbit-2.c
@@ -1,6 +1,6 @@
/* { dg-do compile } */
/* { dg-options "-march=octeon -mbranch-likely -fno-unroll-loops" } */
-/* { dg-skip-if "code quality test" { *-*-* } { "-O0" } { "" } } */
+/* { dg-skip-if "code quality test" { *-*-* } { "-O0" "-Os" } { "" } } */
/* { dg-final { scan-assembler "\tbbit\[01\]\t" } } */
/* { dg-final { scan-assembler-not "\tbbit\[01\]l\t" } } */
/* { dg-final { scan-assembler "\tbnel\t" } } */