FW: [PATCH] [MIPS] microMIPS gcc support

Moore, Catherine Catherine_Moore@mentor.com
Thu Feb 21 02:28:00 GMT 2013



> -----Original Message-----
> From: Richard Sandiford [mailto:rdsandiford@googlemail.com]
> Sent: Tuesday, February 19, 2013 1:25 PM
> To: Moore, Catherine
> Cc: gcc-patches@gcc.gnu.org; Rozycki, Maciej
> Subject: Re: FW: [PATCH] [MIPS] microMIPS gcc support
> 
> Thanks, this is looking much better now.
> 
> 
> > Index: gcc.target/mips/umips-constraints-1.c
> >
> ==========================================================
> =========
> > --- gcc.target/mips/umips-constraints-1.c	(revision 0)
> > +++ gcc.target/mips/umips-constraints-1.c	(revision 0)
> > @@ -0,0 +1,14 @@
> > +/* { dg-options "(-mmicromips)" } */
> > +/* { dg-skip-if "code quality test" { *-*-* } { "-O0" } { "" } } */
> > +
> > +MICROMIPS void
> > +foo (int *x)
> > +{
> > +  asm volatile ("insn1\t%a0" :: "ZD" (&x[0]));
> > +  asm volatile ("insn2\t%a0" :: "ZD" (&x[511]));
> > +  asm volatile ("insn3\t%a0" :: "ZD" (&x[512])); }
> > +
> > +/* { dg-final { scan-assembler "\tinsn1\t0\\(" } } */
> > +/* { dg-final { scan-assembler "\tinsn2\t2044\\(" } } */
> > +/* { dg-final { scan-assembler "\tinsn3\t2048\\(" } } */
> 
> But the insn3 is wrong, isn't it?  I suggested scan-assembler-not for that one
> because I thought it had to be a 12-bit signed offset on microMIPS.  The
> patch has:
> 
Yes, it was wrong.  Now fixed.

> 
> Sorry, only just realised you were skipping -O1.  Please add a comment saying
> why it fails at -O1 or (preferably) add whichever other option is needed for
> the test to pass at -O1.  I assume it's -fpeephole2 in this case.
> 
> Same for all tests with this skip.

-fpeephole2 did the trick.

> 
> > 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?
> 
Yes,  this was the swap_p case.  But it turns out that umips-lpw-swp-1.c was also testing the swap_p case.  I've now dropped this test in favor of a different test that exercises the swap_p = false case.
You had mentioned testing for explicit registers.  This is turning out to be problematic.  The Linux and ELF tool chains don't always use the same register set.  In addition, -O3 seems to expose more opportunities for generating these instructions so the code generated isn't consistent among optimization options.  I've changed it back to just testing for swp, but I'm open to other suggestions.  

> 
> Looks good otherwise, but please post an updated patch.  It's probably
> stating the obvious, but the patch is too invasive for this late stage of 4.8, so
> it'll need to wait until 4.9.
> 

The updated patch is attached.  How's it looking this time?

Thanks,
Catherine
-------------- next part --------------
A non-text attachment was scrubbed...
Name: gcc.cl
Type: application/octet-stream
Size: 5345 bytes
Desc: gcc.cl
URL: <http://gcc.gnu.org/pipermail/gcc-patches/attachments/20130221/8e8990e6/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: gcc.patch
Type: application/octet-stream
Size: 90162 bytes
Desc: gcc.patch
URL: <http://gcc.gnu.org/pipermail/gcc-patches/attachments/20130221/8e8990e6/attachment-0001.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: libgcc.cl
Type: application/octet-stream
Size: 296 bytes
Desc: libgcc.cl
URL: <http://gcc.gnu.org/pipermail/gcc-patches/attachments/20130221/8e8990e6/attachment-0002.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: libgcc.patch
Type: application/octet-stream
Size: 2195 bytes
Desc: libgcc.patch
URL: <http://gcc.gnu.org/pipermail/gcc-patches/attachments/20130221/8e8990e6/attachment-0003.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: gcc-testsuite.cl
Type: application/octet-stream
Size: 620 bytes
Desc: gcc-testsuite.cl
URL: <http://gcc.gnu.org/pipermail/gcc-patches/attachments/20130221/8e8990e6/attachment-0004.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: gcc-testsuite.patch
Type: application/octet-stream
Size: 12793 bytes
Desc: gcc-testsuite.patch
URL: <http://gcc.gnu.org/pipermail/gcc-patches/attachments/20130221/8e8990e6/attachment-0005.obj>


More information about the Gcc-patches mailing list