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: [PATCH] ARM pre-indexing adress mode for absolute addresses


On Fri, 9 Sep 2005, Richard Earnshaw wrote:

> On Fri, 2005-09-09 at 06:09, Nicolas Pitre wrote:
> > Anyway, here's a tentative fix.  It actually does fix the problem and 
> > still generate expected code for loads and stores to absolute memory 
> > addresses.  I'm just not sure if that's the most appropriate fix.  
> > Comments?
> > 
> > Index: config/arm/arm.c
> > ===================================================================
> > RCS file: /cvs/gcc/gcc/gcc/config/arm/arm.c,v
> > retrieving revision 1.478
> > diff -u -r1.478 arm.c
> > --- config/arm/arm.c	2 Sep 2005 19:09:33 -0000	1.478
> > +++ config/arm/arm.c	9 Sep 2005 05:02:48 -0000
> > @@ -3780,7 +3780,7 @@
> >  	  index -= mask;
> >  	}
> >        base_reg = force_reg (SImode, GEN_INT (base));
> > -      x = gen_rtx_PLUS (SImode, base_reg, GEN_INT (index));
> > +      x = force_reg (SImode, gen_rtx_PLUS (SImode, base_reg, GEN_INT (index)));
> >      }
> >  
> >    if (flag_pic)
> 
> I think you've just uncovered a latent bug, but you should be using 
> 
> 	plus_constant (base_reg, index)
> 
> rather than gen_rtx_PLUS.  For the testcase given that will fix the bug,
> but a trivial change to form a more complex constant address (such as
> 0x12345) will cause it to re-appear. 

Indeed.

> I don't think you need to do more than that here: in particular, there
> should be no need to force the final result into a register;
> arm_legitimize_address is allowed to fail, and producing an invalid
> address sequence is one of the failure mechanisms (it's validated after
> generation).  

OK.

> The real problem is that on ARM (call (mem (xxx)) has completely
> different constraints on xxx to a normal memory reference.  I think
> there's a bug either in the way expand_call works or in the ARM call
> expander patterns that means that addresses aren't getting validated
> properly.

This is quickly getting a bit above my head though.

In fact with my "fix" I noticed some effects with the generated address 
to branch to getting split suboptimally since it was expected to be used 
with an ldr or str not with a mov pc, rx.  I was therefore wondering if 
the address split for proper preindexing should not be done within the 
appropriate move pattern instead, leaving the call pattern unaffected?


Nicolas


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