From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 94940 invoked by alias); 30 Oct 2018 22:44:29 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 94902 invoked by uid 89); 30 Oct 2018 22:44:27 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy=Hx-spam-relays-external:209.85.214.195, H*RU:209.85.214.195, H*r:sk:bb7-v6s X-HELO: mail-pl1-f195.google.com Received: from mail-pl1-f195.google.com (HELO mail-pl1-f195.google.com) (209.85.214.195) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 30 Oct 2018 22:44:25 +0000 Received: by mail-pl1-f195.google.com with SMTP id bb7-v6so6255016plb.13 for ; Tue, 30 Oct 2018 15:44:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=m6Clw+WyviEfVGVolIXAsqGMq9if+6T0WPaYr4xLgD0=; b=Wz6sEKlumU5oTcWu7feeRmyCzTkMDehNEJyig2bp5/p28veE2ed6Pxl28HjNuC1RSX mUGp2Ci6wHOC3/TFbHog9z2RQ68ZUeoqcHmA8g8Hj9euL0gz6QmfFYFBVRrQG1oOvCpc MYDQHEVKcW1cJG+CE+dCTJdx0PrtglF1MEol/6u9jeHoxhHcMQ/CO6SJjp9S9KLpF8iZ tGVIIMUsUZEC+58OKXggaMohKBMPC+2XqHlNqbZhDeBzTDBHQopbym/2nU9PgJyDDzoN XIJoMrsue0qh8y2wVnbCHJq7JE2zbvpRyJt7Jat7BV/L9Dpki45ThkCtsbYKlxTwTgmJ 0kgw== Return-Path: Received: from localhost (g148.61-193-223.ppp.wakwak.ne.jp. [61.193.223.148]) by smtp.gmail.com with ESMTPSA id p12-v6sm3712234pgj.6.2018.10.30.15.44.22 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Tue, 30 Oct 2018 15:44:22 -0700 (PDT) Date: Wed, 31 Oct 2018 04:38:00 -0000 From: Stafford Horne To: Richard Henderson Cc: GCC patches , Openrisc , Jeff Law , Joseph Myers , Joel Sherrill , Sebastian Huber Subject: Re: [PATCH v3 3/3] or1k: gcc: initial support for openrisc Message-ID: <20181030224420.GE2843@lianli.shorne-pla.net> References: <20181027043702.18414-1-shorne@gmail.com> <20181027043702.18414-4-shorne@gmail.com> <20181030121806.GB2843@lianli.shorne-pla.net> <0d25c0ba-7de0-668c-ebcb-350d17029846@twiddle.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <0d25c0ba-7de0-668c-ebcb-350d17029846@twiddle.net> User-Agent: Mutt/1.10.1 (2018-07-13) X-IsSubscribed: yes X-SW-Source: 2018-10/txt/msg01981.txt.bz2 On Tue, Oct 30, 2018 at 03:57:03PM +0000, Richard Henderson wrote: > On 10/30/18 12:18 PM, Stafford Horne wrote: > > OK, I was just being lazy allowing the spill. Do you think the split/expand > > would be an RTL using left shift / right shift? Can you think of something > > more clever? Since "real" hardware does not usually support shifts with an > > immediate we will need 1 instruction to load shift amount. i.e. > > > > l.ori %0, r0, 24 > > l.sll %1, %1, %0 > > l.sra %0, %1, %0 > > This clobbers %1. Right, it was just a rough idea to create another r/r pattern. > So, ouch. I think we will want to avoid creating this particular pattern in > the first place unless l.exts exists then. We would use another pattern like > > (define_insn "*sign_extend_mem" > [(set (match_operand:SI 0 "register_operand" "=r") > (sign_extend:SI > (match_operand:HI 1 "memory_operand" "m")))] > "" > "l.lhs\t%0, %1") > > following the TARGET_SEXT pattern. In this way combine can use this pattern > without getting us into trouble with the register allocator later. OK, thats simple enough then. I had thought you were asking for creating another r/r pattern using define_split. That might be better than requiring a memory load/store to do sign extension, but I guess we can optimize that later if needed. (Thats what my original thought was.) -Stafford