Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1760042AbbEEQKp (ORCPT ); Tue, 5 May 2015 12:10:45 -0400 Received: from mail-ig0-f175.google.com ([209.85.213.175]:36542 "EHLO mail-ig0-f175.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2993419AbbEEPhD (ORCPT ); Tue, 5 May 2015 11:37:03 -0400 MIME-Version: 1.0 In-Reply-To: <20150505135005.GA4850@gate.crashing.org> References: <20150501151630.GH5029@twins.programming.kicks-ass.net> <20150501163329.GU1751@tucnak.redhat.com> <5543CDC0.6010206@redhat.com> <20150502123958.GK5029@twins.programming.kicks-ass.net> <5547C992.9000703@redhat.com> <20150505135005.GA4850@gate.crashing.org> Date: Tue, 5 May 2015 08:37:01 -0700 X-Google-Sender-Auth: BTi2cVoBlGNC-hf2e0W7VRHVGuM Message-ID: Subject: Re: [RFC] Design for flag bit outputs from asms From: Linus Torvalds To: Segher Boessenkool Cc: Richard Henderson , Peter Zijlstra , Vladimir Makarov , Jakub Jelinek , Ingo Molnar , "H. Peter Anvin" , Thomas Gleixner , Linux Kernel Mailing List , Borislav Petkov , "gcc@gcc.gnu.org" Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1747 Lines: 37 On Tue, May 5, 2015 at 6:50 AM, Segher Boessenkool wrote: > > Since it is pre-processed, there is no real reason to overlap this with > the constraints namespace; we could have e.g. "=@[xy]" (and "@[xy]" for > inputs) mean the target needs to do some "xy" transform here. In fact, standing out visually would be just a good thing, since it's pretty special even from a usage standpoint. And are you actually planning to have flags as inputs? Because *that* sounds like a bad idea. It's pretty hard to turn a boolean into a flag value, while pretty much any archiecture has an operation like "setcc" to go the other way. And I don't think your machine descriptions have anything to "generate flags". You'd have to add fragile and complex machinery for something it is unlikely anybody ever wants. Flag *outputs* people definitely want. Flag inputs? Yeah, I can absolutely see the carry flag being useful for multi-precision arithmetic, but it's *so* hard to guarantee that it still is live, that in practice the compiler would likely have to re-generate it from a value anyway, so ... So I'd go for output-only, and make the syntax be something very visually unambiguous. That "=@[xy]" format looks fine, where "xy" would be very architecture-dependent. Or make it even *more* specific by using "CC" for condition codes, and make the syntax "=@CC[xy]", in case you ever want to use the "@" marker for any other kind of magic constraint. Linus -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/