Re: [RFA:] Adjust documentation for LEGITIMATE_CONSTANT_P et al to match reality

[Hans-Peter Nilsson <hans-peter dot nilsson at axis dot com>]

> From: Richard Sandiford <rdsandiford@googlemail.com>
> Date: Sun, 07 Sep 2008 20:45:38 +0100

> Hans-Peter Nilsson <hans-peter.nilsson@axis.com> writes:
> Well, my message said both what I think the current rules are
> (first set of grammar rules) and what I think they ought to be
> (second set of grammar rules).  As for implementing it, that's
> what I started trying to do with my PowerPC patch.
> 
> > In the meantime, let's have documentation that matches the code.
> 
> But my point was that the proposed documentation doesn't match the code.

Well, I think it does.  No rules are explicit there.
If it's overly general, that's erroring on the safe side.

If we *do* define rules, then the target still has to validize
the subset it accepts, so saying "you can get any arithmetic
canonical RTX in a CONST, please validize what you handle by
defining these macros" isn't that far from "you can get any of
these:... in a CONST, please validize what you handle by
defining these macros".

> You seem to be claiming that a move expander has to cope with a CONST
> containing any unsimplifiable rtx expression whose terms are CONST_OBJs
> or UNSPECs (UNSPECs should be treated as black-box terms here),
> or something akin to that.

No, I certainly didn't.  Attempted transformations to the RTX
are validized, so all the target has to do is provide the
"right" predicate macros.  Move-insns are only created for
whatever CONST contents were accepted originally.  Maybe there
are rules as to what trees are transformed into RTX, so we don't
get the ashiftrt kind of oddity in the first place.

>  But I see no evidence that the target-
> independent code can create anything so general.  And certainly
> no port copes with all such CONSTs.

In move insns?  Not my strawman; wrong tree...

Many ports define a non-1 LEGITIMATE_CONSTANT_P, that's as far
"coping" as should be necessary.

> Going back to the example, you say:
> 
> >> E.g. most ports would barf at:
> >> 
> >>    (const (ashiftrt (and (symbol_ref ...)
> >>                          (const_int ...))
> >>                     (const_int ...)))
> >> 
> >> Does that count as "algorithmically valid"?
> >
> > If there are such operators with data dependence on
> > symbol_ref's, I don't see why stops that from happening.
> 
> but it's clear that no port currently handles this, even though
> this expression can be constructed in C code using intptr_ts.

Again, all that is needed is that it's refused by the macros I
touched in the documentation update.

> Both quoted terms still seem too vague to me (and too general
> for the current code).

It's a damn shot better than recommending a 1 for LEGITIMATE_CONSTANT_P!

> >> Likewise, the target-independent code must have some assurances about
> >> the kinds of CONST that the target code creates.  Otherwise, it won't
> >> be able to make any guarantees about the expressions it creates itself.
> >> E.g. if a backend creates something that simplifies to (const (plus X X)),
> >> can/should the target-independent code rewrite that as
> >> (const (ashift X 2))?
> >
> > A target would be right to refuse non-canonical RTX and for
> > that, the canonical representation is (MULT X 2).
> 
> It depends on context.  ASHIFT is canonical in some places, MULT in others.

Uh, that's a pre-existing flaw, you can't expect me to fix that
too.  Besides, moot: I can't think of a target that wouldn't
have to refuse that kind of CONST in the macros - if not only
for lack of canonical representation!

Still, we have LEGITIMATE_CONSTANT_P and CONSTANT_ADDRESS_P -
although outside a MEM you can't tell one from the other.

brgds, H-P