From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-return-199936-listarch-gcc=gcc.gnu.org@gcc.gnu.org>
Received: (qmail 125355 invoked by alias); 19 Aug 2019 07:36:00 -0000
Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc.gcc.gnu.org>
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 125347 invoked by uid 89); 19 Aug 2019 07:35:59 -0000
Authentication-Results: sourceware.org; auth=none
X-Spam-SWARE-Status: No, score=-4.4 required=5.0 tests=AWL,BAYES_20,SPF_PASS autolearn=ham version=3.3.1 spammy=H*F:U*john, H*F:D*au, H*Ad:D*au, Vladimir
X-HELO: jocasta.intra
Received: from de.cellform.com (HELO jocasta.intra) (88.217.224.109) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 19 Aug 2019 07:35:58 +0000
Received: from jocasta.intra (localhost [127.0.0.1])	by jocasta.intra (8.15.2/8.15.2/Debian-8) with ESMTPS id x7J7ZreX000973	(version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT);	Mon, 19 Aug 2019 09:35:53 +0200
Received: (from john@localhost)	by jocasta.intra (8.15.2/8.15.2/Submit) id x7J7ZrUZ000972;	Mon, 19 Aug 2019 09:35:53 +0200
Date: Mon, 19 Aug 2019 07:36:00 -0000
From: John Darrington <john@darrington.wattle.id.au>
To: Vladimir Makarov <vmakarov@redhat.com>
Cc: John Darrington <john@darrington.wattle.id.au>, gcc@gcc.gnu.org
Subject: Re: Special Memory Constraint [was Re: Indirect memory addresses vs. lra]
Message-ID: <20190819073553.pi644qzyokxmynr2@jocasta.intra>
References: <20190808191914.GK31406@gate.crashing.org> <dca38a3f-91db-9483-dd0e-0075ef501624@redhat.com> <20190809081439.baoyu3ii5i2qfbzt@jocasta.intra> <70b9bcc9-e12a-78b4-b8cc-a67b7ca3d38d@redhat.com> <20190810060553.m6e42sovw7s4xqoa@jocasta.intra> <be60bf0c-c5f4-dff1-267c-d426d0c6c44e@redhat.com> <20190815173559.kbp3uja7jklx74iy@jocasta.intra> <3c6c87ce-a38f-728d-e083-aa066d531790@redhat.com> <20190816112357.ep7fns6skm5emoey@jocasta.intra> <5693be1f-4351-94ab-9096-f6e4f9f875c1@redhat.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <5693be1f-4351-94ab-9096-f6e4f9f875c1@redhat.com>
User-Agent: NeoMutt/20170113 (1.7.2)
X-IsSubscribed: yes
X-SW-Source: 2019-08/txt/msg00130.txt.bz2

On Fri, Aug 16, 2019 at 10:50:13AM -0400, Vladimir Makarov wrote:
     
     
     No I meant something like that
     
     (define_special_memory_constraint "a" ...)
     (define_predicate "my_special_predicate" ...
     		
      {
        if (lra_in_progress_p)
          return REG_P (op) && REGNO (op) >= FIRST_PSEUDO_REGISTER && reg_renumber[REGNO(op)] < 0;
        return true if memory with sp addressing;
     })
     
     I think LRA spills pseudo-register and it will be memory addressed by sp
     at the end of LRA.

What I've done is this:

(define_predicate "my_special_predicate"
		    (match_operand 0 "memory_operand")
 {
   debug_rtx (op);
   gcc_assert (MEM_P (op));
   op = XEXP (op, 0);
   if (GET_CODE (op) == PLUS)
     op = XEXP (op, 0);

   if (lra_in_progress)
     {
       fprintf (stderr, "%s:%d\n", __FILE__, __LINE__);
       return REG_P (op) && REGNO (op) >= FIRST_PSEUDO_REGISTER && reg_renumber[REGNO(op)] < 0;
     }


   if (REG_P (op))
     {
       int regno = REGNO (op);
       return (regno == 10); // register is the stack pointer
     }

   return true;
 })

 (and many variations)  Unfortunately, any moderately complicated input
 still results in a (mem (reg) ) insn repeatedly entering the
 lra_in_progress case and returning false, and eventually terminating with
     
 "internal compiler error: maximum number of generated reload insns per insn achieved (90)"


Any other ideas?

J'