This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [RFA:] Adjust documentation for LEGITIMATE_CONSTANT_P et al to match reality, take 2
- From: Richard Sandiford <rdsandiford at googlemail dot com>
- To: Hans-Peter Nilsson <hans-peter dot nilsson at axis dot com>
- Cc: gcc-patches at gcc dot gnu dot org
- Date: Sun, 05 Oct 2008 21:44:25 +0100
- Subject: Re: [RFA:] Adjust documentation for LEGITIMATE_CONSTANT_P et al to match reality, take 2
- References: <200810051757.m95HvpJl031659@ignucius.se.axis.com>
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