Re: [PATCH] BZ60501: Add addptr optab

[Vladimir Makarov <vmakarov at redhat dot com>]

On 2014-03-13, 7:37 AM, Andreas Krebbel wrote:
> On 13/03/14 12:25, Richard Biener wrote:
> > On Thu, Mar 13, 2014 at 12:16 PM, Eric Botcazou <ebotcazou@adacore.com> wrote:
> > > > --- a/gcc/doc/md.texi
> > > > +++ b/gcc/doc/md.texi
> > > > @@ -4720,6 +4720,17 @@ Add operand 2 and operand 1, storing the result in
> > > > operand 0.  All operands must have mode @var{m}.  This can be used even on
> > > > two-address machines, by means of constraints requiring operands 1 and 0 to
> > > > be the same location.
> > > >
> > > > +@cindex @code{addptr@var{m}3} instruction pattern
> > > > +@item @samp{addptr@var{m}3}
> > > > +Like @code{addptr@var{m}3} but does never clobber the condition code.
> > > > +It only needs to be defined if @code{add@var{m}3} either sets the
> > > > +condition code or address calculations cannot be performed with the
> > > > +normal add instructions due to other reasons.  If adds used for
> > > > +address calculations and normal adds are not compatible it is required
> > > > +to expand a distinct pattern (e.g. using an unspec).  The pattern is
> > > > +used by LRA to emit address calculations.  @code{add@var{m}3} is used
> > > > +if @code{addptr@var{m}3} is not defined.
> > >
> > > I'm a bit skeptical of the "address calculations cannot be performed with the
> > > normal add instructions due to other reasons" part".  Surely they can be
> > > performed on all architectures supported by GCC as of this writing, otherwise
> > > how would the compiler even work?  And if it's really like @code{add@var{m}3},
> > > why restricting it to addresses, i.e. why calling it @code{addptr@var{m}3}?
> > > Does that come from an implementation constraint on s390 that supports it only
> > > for a subset of the cases supported by @code{add@var{m}3}?
> >
> > Yeah, isn't it that you want a named pattern like add_nocc for an add
> > that doesn't clobber flags?
> This would suggest that you can use the pattern also for performing a normal add in case the
> condition code is not needed afterwards but this isn't correct for s390 31 bit where an address
> calculation is actually something different.  addptr is better I think because it is a pattern which
> is supposed to be implemented with a load address instruction and the middle-end guarantees to use
> it only on addresses. (I hope LRA is actually behaving that way). Perhaps loadptr or la or
> loadaddress would be a better name?

It is complicated.  There is no guarantee that it is used only for 
addresses.  I need some time to think how to fix it.

Meanwhile, you *should* commit the patch into the trunk because it 
solves the real problem.  And I can work from this to make changes that 
the new pattern is only used for addresses.

The patch is absolutely safe for all targets but s390.  There is still a 
tiny possibility that it might result in some problems for s390  (now I 
see only one situation when a pseudo in a subreg changed by equiv plus 
expr needs a reload).  In any case your patch solves real numerous 
failures and can be used as a base for further work.

Thanks for working on this problem, Andreas.  Sorry that I missed the 
PR60501.