| Submitter | Steve Ellcey |
|---|---|
| Date | Oct. 8, 2012, 4:21 p.m. |
| Message ID | <9bd1abff-65e1-488e-ba9b-0e0ea8d90abe@EXCHHUB01.MIPS.com> |
| Download | mbox | patch |
| Permalink | /patch/190057/ |
| State | New |
| Headers | show |
Comments
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.
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" } } */