This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: FW: [PATCH] [MIPS] microMIPS gcc support


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]