From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 111280 invoked by alias); 28 Feb 2019 04:16:52 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 111254 invoked by uid 89); 28 Feb 2019 04:16:51 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.2 spammy=rectified, taught, hrm, Anything X-HELO: gate.crashing.org Received: from gate.crashing.org (HELO gate.crashing.org) (63.228.1.57) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 28 Feb 2019 04:16:49 +0000 Received: from gate.crashing.org (localhost.localdomain [127.0.0.1]) by gate.crashing.org (8.14.1/8.14.1) with ESMTP id x1Q2hmv8003895; Mon, 25 Feb 2019 20:43:48 -0600 Received: (from segher@localhost) by gate.crashing.org (8.14.1/8.14.1/Submit) id x1PNAwZt024742; Mon, 25 Feb 2019 17:10:58 -0600 Date: Thu, 28 Feb 2019 04:16:00 -0000 From: Segher Boessenkool To: Michael Matz Cc: Peter Bergner , Alan Modra , GCC Subject: Re: Question regarding constraint usage within inline asm Message-ID: <20190225231054.GH14180@gate.crashing.org> References: <20190220030958.GC16787@bubble.grove.modra.org> <61bb9a58-0d4c-70e9-7611-3169de0c8950@linux.ibm.com> <20190220220437.GC23427@bubble.grove.modra.org> <20190220221933.GD23427@bubble.grove.modra.org> <20190221033958.GE23427@bubble.grove.modra.org> <8608623a-3891-1971-06d7-1e2aaf8bf113@linux.ibm.com> <20190222010704.GB14180@gate.crashing.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-IsSubscribed: yes X-SW-Source: 2019-02/txt/msg00168.txt.bz2 Hi! On Mon, Feb 25, 2019 at 06:32:53PM +0000, Michael Matz wrote: > On Thu, 21 Feb 2019, Segher Boessenkool wrote: > > > That said, the "bug" in the case we're seeing, is that asmcons rewrote > > > all of "input"'s pseudos, and it should be more careful to not create > > > rtl with illegal constraint usage that LRA cannot fix up. With the > > > fix, operand %1 in the inline asm is no longer hard coded to r3 and it > > > uses the pseudo instead, so everything is copacetic. > > > > And that expand used one pseudo for everything in the asm is bad > > already. > > I'll contest that. Asms aren't that special from an input-output > perspective and shouldn't be (makes for clearer and hence more correct > code). hardregs are special, OTOH. expand doesn't (and shouldn't) do > anything special for > > _2 = _1 + _1; > > (i.e. it should assign the same pseudo to both inputs), from which follows > that it shouldn't do anything special for > > asm("" : "=r" (_2) : "r" (_1), "w" (_1)) > > either. The picture changes if _1 corresponds to a local decl with an > associated hard reg; those don't get SSA names for a reason. But I > believe you're worrying about the common case of off-the-mill SSA > names. Yup. All good points, I didn't think this through enough obviously. The _1+_1 isn't great if that single pseudo then ends up in mem (it will need a reload again on most archs, probably causing another spill), btw. > Anything that would cause breakage by such behaviour of expand is to be > rectified by LRA/reload, not by hackery within expand. You get worse code that way. Reload is much too late to make optimised code, and that isn't its task anyway: its task is to make something that works where the passes before it couldn't manage. Yes, reload should be able to fix up anything (well, within some limits). That is not an excuse to generate code that we know will need such fixups though. I suppose check_asm_operands needs to be taught a bit more strict rules as well about what is a valid asm. Hrm. A lot to think about :-) Segher