From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-return-49682-listarch-gcc=gcc.gnu.org@gcc.gnu.org>
Received: (qmail 17863 invoked by alias); 9 Apr 2002 12:14:09 -0000
Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Archive: <http://gcc.gnu.org/ml/gcc/>
List-Post: <mailto:gcc@gcc.gnu.org>
List-Help: <http://gcc.gnu.org/ml/>
Sender: gcc-owner@gcc.gnu.org
Received: (qmail 17825 invoked from network); 9 Apr 2002 12:14:07 -0000
Received: from unknown (HELO pizda.ninka.net) (216.101.162.242)
  by sources.redhat.com with SMTP; 9 Apr 2002 12:14:07 -0000
Received: from localhost (IDENT:davem@localhost.localdomain [127.0.0.1])
	by pizda.ninka.net (8.9.3/8.9.3) with ESMTP id FAA09322
	for <gcc@gcc.gnu.org>; Tue, 9 Apr 2002 05:07:15 -0700
Date: Tue, 09 Apr 2002 05:19:00 -0000
Message-Id: <20020409.050715.75514317.davem@redhat.com>
To: gcc@gcc.gnu.org
Subject: Undocumented anomaly with EXTRA_CONSTRAINTS
From: "David S. Miller" <davem@redhat.com>
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-SW-Source: 2002-04/txt/msg00334.txt.bz2


As per the documentation and usage, EXTRA_CONSTRANT is for
"Special cases of registers or memory."

Fine so far, but one has to be really careful when using
this for memory operands.  Specifically I just fixed a bug
(patch to gcc-patches and commit to come after my regressions
run) in the Sparc port that appears to be present in other
ports as well.

Consider how constrain_operands works, and also how reload
checks the constraints.  In particular, look at how the 'm'
works.  In constrain_operands it passes if:

	GET_CODE (op) == MEM
	/* Before reload, accept what reload can turn into mem.  */
	|| (strict < 0 && CONSTANT_P (op))
	/* During reload, accept a pseudo  */
	|| (reload_in_progress && GET_CODE (op) == REG
	    && REGNO (op) >= FIRST_PSEUDO_REGISTER)

In the reload case the test is (let us call this the
REG_OK_STRICT case, since that is what it is):

	GET_CODE (operand) == MEM
	|| (GET_CODE (operand) == REG
	    && REGNO (operand) >= FIRST_PSEUDO_REGISTER
	    && reg_renumber[REGNO (operand)] < 0)

These extra:

	1) accept any pseudo if !REG_OK_STRICT
	2) accept only non-renumbered pseudos if REG_OK_STRICT

checks in their memory EXTRA_CONTRAINT entries aren't documented.

Which means that anyone making a mistake here can end up with "severe
tire damage" in reload.

I note that the PA port specifically makes note of this issue with
it's IS_RELOADING_PSEUDO_P macro.  Hi Jeff. :-)  In fact I want to
quote Jeff's comments in the PA headers above the EXTRA_CONSTRAINT
definition because it sums up my email:

   Note that an unassigned pseudo register is such a memory operand.
   Needed because reload will generate these things in insns and then
   not re-recognize the insns, causing constrain_operands to fail.

Anyways, the gist of my email is:

1) Am I right?
2) Once decided, we should document this and perhaps even
   "help" the port somehow.

By "help" the port, I mean we can somehow hide these recog/reload
details about accepting pseudo-registers for memory constraints.