From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1661 invoked by alias); 9 Apr 2002 13:57:50 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 1641 invoked from network); 9 Apr 2002 13:57:48 -0000 Received: from unknown (HELO mail.cs.tu-berlin.de) (130.149.17.13) by sources.redhat.com with SMTP; 9 Apr 2002 13:57:48 -0000 Received: from platon.cs.tu-berlin.de (matzmich@platon.cs.tu-berlin.de [130.149.25.107]) by mail.cs.tu-berlin.de (8.9.3/8.9.3) with ESMTP id PAA13917; Tue, 9 Apr 2002 15:55:39 +0200 (MET DST) Received: (from matzmich@localhost) by platon.cs.tu-berlin.de (8.9.3/8.9.3) id PAA28526; Tue, 9 Apr 2002 15:55:37 +0200 (MET DST) Date: Tue, 09 Apr 2002 07:08:00 -0000 From: Michael Matz X-X-Sender: To: "David S. Miller" cc: Subject: Re: Undocumented anomaly with EXTRA_CONSTRAINTS In-Reply-To: <20020409.061552.77173492.davem@redhat.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-SW-Source: 2002-04/txt/msg00344.txt.bz2 Hi, On Tue, 9 Apr 2002, David S. Miller wrote: > I'm not quite sure what this has to do with only EXTRA_CONSTRAINT. Any > 'm' constraint accepts pseudos before reload and unassigned pseudos while > reloading. Exactly because unassigned pseudos _are_ memory slots. > > Where is this documented? :-) Ohh I see. Guess I stared too long at reload ;) Indeed documenting this might be usefull (if not already done so), like would be documenting reload at all ;) That pa.h macro probably is usefull globally, I'm just not sure, how finegraned it should be. I could think of the usefullness of a POSSIBLY_MEM_P(rtx) (checking for MEM and before reload also pseudo, while reload unassigned pseudos). The pa.h macro as is is rather limited, as it only does anything while reload. But before reload pseudos are valid memory too (constrain-wise at least). After reload, of course only real MEMs are valid. Just to be complete: Also 'o' (offsetable mems) accepts such pseudos in certain circumstances (although this remark doesn't relate to any self-written extra constraints accepting mem's). > That's the point of my entire email. If all one did was read md.texi, > upon implementing EXTRA_CONSTRAINT for MEM objects this issue would > not be apparent until the compiler started to fail. Hmm, but you can define those EXTRA_CONSTRAINTS any way you like, or can't you? I.e. if you define one which accepts only a MEM rtx, are you saying that this breaks, and it really also should accept a pseudo? This should only happen, if the pattern itself accepts that pseudo, which would be a bug in the .md file, if there's no alternative whose constraints accept the pseudo. Ciao, Michael.