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


Hans-Peter Nilsson <hans-peter.nilsson@axis.com> writes:
>> 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...

The tone of this thread seems to be degenerating, so I'm a little
hesitant to respond, but: removing the const minus generation from
the middle-end is indeed the idea.  It's waiting for a Darwin
maintainer to review the Darwin patch; every other pre-requisite
has been approved.

To be clear, I think using UNSPECs instead of const minus is a step
forward in its own right, and would be even if the const minus stuff
in simplify-rtx.c weren't needed.  See the covering messages for
details, including an unwanted canonicalisation we get when simplifying
(minus X Y) - 1.

If that's approved, I think there would be nothing to stop us removing
the const minus code, which again seems like an improvement in its
own right.  The code handles a very special case, and isn't consistent
with routines like plus_constant.

With the const minus simplifications gone, do you know of any other code
that would generate unexpected CONSTs?

Richard


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