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: [RFA:] Adjust documentation for LEGITIMATE_CONSTANT_P et al to match reality, take 2


> From: Richard Sandiford <rdsandiford@googlemail.com>
> Date: Tue, 23 Sep 2008 20:22:46 +0100

> Hans-Peter Nilsson <hans-peter.nilsson@axis.com> writes:
> > See the thread at
> > <http://gcc.gnu.org/ml/gcc-patches/2008-09/msg00552.html>.  This
> > update merges, with a single s/code/type/ for CONSTANT_P, mine
> > and Paolo Bonzini's attempts and hopefully addresses most of
> > Richard Sandiford's objections.  I hope most agree this is a
> > reasonable step forward and that the discontented not see it as
> > a step backward.
> 
> Can we wait until we know which way 4.4 goes wrt (const (minus ...))?
> If we go for something like the grammar I suggested, this:

I've waited, and I think we know now: it does just the same.
It's stage 3 and I don't see any progress on your suggested
rules, so it seems we're going nowhere.

> > +is a valid address.  A port can use @code{CONSTANT_P (@var{x})} to
> > +simplify the expression, but must always validize the contents of
> > +a @code{CONST} expression.
> >  @end defmac
> 
> wouldn't always be necessary on CISCy targets, just as it traditionally
> hasn't been in the past.
> 
> I don't think it's productive to argue over the fine detail until we
> know what 4.4 does.

What fine detail?  What is it that we don't know?  I see
long-standing regression failures for my target.  As it stands,
it is necessary to do what my documentation change suggests, and
documenting it would be an improvement over status quo.  Why
can't I document what the code does, even in the suggested vague
terms?  Can't we do that, and *then* document and enforce your
rules?

You're the one protesting this and asking to wait, but I don't
see any patches along that route.  One would be quite welcomed.
How about a patch to tm.texi documenting your suggestions, for
starters?

Or should we remove the expicit const minus generation in the
middle end and look the other way wrt. CONST rules?  I'm fine
with that too.  Maybe such a change wouldn't even break ppc
anymore...

brgds, H-P


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