On Tue, 19 Feb 2013, Richard Sandiford wrote:
> > Index: gcc.target/mips/umips-lwp-swp-2.c
> > ===================================================================
> > --- gcc.target/mips/umips-lwp-swp-2.c (revision 0)
> > +++ gcc.target/mips/umips-lwp-swp-2.c (revision 0)
> > @@ -0,0 +1,19 @@
> > +/* { dg-options "-mgp32 (-mmicromips)" } */
> > +/* { dg-skip-if "code quality test" { *-*-* } { "-O0" "-O1" "-Os" } { "" }
> > } */
> > +int a[2];
> > +
> > +MICROMIPS f (b)
> > +{
> > + unsigned int i;
> > + int *p;
> > + for (p = &a[b], i = b; --i < ~0; )
> > + *--p = i * 3 + (int)a;
> > +
> > +}
> > +
> > +MICROMIPS main ()
> > +{
> > + a[0] = a[1] = 0;
> > + f (2);
> > +}
> > +/* { dg-final { scan-assembler "\tswp\t\\\$3,0\\(\\\$3\\)" } }*/
>
> Is this a test of the swap_p case? Thanks if so, but could you add a
> comment saying where the SWP gets generated, and why the test needs
> to be skipped at -O1 and -Os?
TBH, it is -Os where size really matters, so IMHO it is the -Os
optimisation level where LWP/SWP should be used where possible in the
first place, even if it hurts performance for some reason (and where e.g.
-O2 might decide to go for individual accesses instead).
Not to be meant as a show-stopper for this initial implementation, but if
the optimisation does not work for LWP/SWP at -Os for some reason, then I
think there's something going seriously wrong somewhere (instruction
lengths set wrong for example?) which looks to me worth investigating and
acting upon accordingly as the next step.
I saw cases with instruction lengths set too high with our trunk just
about yesterday and MIPS16 code, e.g.:
.file 1 "foo.c"
.section .mdebug.abi32
.previous
.gnu_attribute 4, 1
.abicalls
.option pic0
.text
.align 2
.globl foo
.set mips16
.ent foo
.type foo, @function
foo:
.frame $sp,32,$31 # vars= 0, regs= 1/0, args= 16, gp= 8
.mask 0x80000000,-4
.fmask 0x00000000,0
save 32,$31 # 11 *mips16e_save_restore [length = 4]
.set noreorder
.set nomacro
jal bar # 22 call_split/2 [length = 8]
li $4,0 # 5 *movsi_mips16/4 [length = 4]
.set macro
.set reorder
restore 32,$31 # 18 *mips16e_save_restore [length = 4]
j $31 # 20 simple_return_internal [length = 2]
.end foo
.size foo, .-foo
-- it looks all wrong to me except for the final J. Of course I realise
where it originally comes from, but I think it would be good if the
initial pessimistic estimates were actually adjusted as more is known
about actual insns produced.
I wonder if we may have similar issues with microMIPS instruction size
calculation triggering here.
Maciej
