Subject: Re: ASM flags in general
To: "H. Peter Anvin" <hpa@zytor.com>, Uros Bizjak <uros_bizjak1@t-2.net>,
        linux-kernel@vger.kernel.org
References: <1438019319-19731-1-git-send-email-uros_bizjak1@t-2.net>
 <55B680D8.5070702@zytor.com>
Cc: x86@kernel.org, Uros Bizjak <ubizjak@gmail.com>,
        Ingo Molnar <mingo@kernel.org>
From: Andy Lutomirski <luto@kernel.org>
Message-ID: <55B696B2.3000702@kernel.org>
Date: Mon, 27 Jul 2015 13:38:10 -0700
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101
 Thunderbird/38.0.1
MIME-Version: 1.0
In-Reply-To: <55B680D8.5070702@zytor.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 3456
Lines: 104

On 07/27/2015 12:04 PM, H. Peter Anvin wrote:
> On 07/27/2015 10:48 AM, Uros Bizjak wrote:
>> From: Uros Bizjak <ubizjak@gmail.com>
>>
>> This patch introduces GCC ASM flags to bitops.
>>
>> The new functionality depends on __GCC_ASM_FLAG_OUTPUTS__ preprocessor
>> symbol, which is automatically set by GCC version 6 or later when
>> ASM flags feature is supported.
>>
>> The improvement can be illustrated with following code snipped.
>> Instead of:
>>
>
> This might be a good time to bring up this proposal I made in private
> recently in public:
>
> In the next version (6.0) of gcc, there will be support for emitting
> flags as outputs from inline assembly.  We obviously want to use this,
> but I think it would be better to not have to have two copies for each
> bit of assembly, for old and new gcc.
>
> I have been thinking about it, and have checked with how gcc actually
> handles "bool" as outputs.  It turns out that using "bool" in asm output
> is perfectly well defined on x86, and is defined as a byte output which
> is required to be 0 or 1.  This is consistent with how the "set"
> instruction operates.
>
> As such, I would like to propose the following:
>
> 1. We change the actual type of the output variable for these asm
> statements to bool.
> 2. Define the following macros:
>
> #ifdef __GCC_ASM_FLAGS_OUTPUT__
>
> #define CC_SET(c)
> #define CC_OUT(c) "=@cc" #c
>
> #else
>
> #define CC_SET(c) "\n\tset" #c " %[cc_" #c "]"
> #define CC_OUT(c) [cc_ ## c] "=qm" (v)
>
> #endif
>
>
> A sample use would be something like this:
>
> unsigned long x, y, z;
> bool carry;
>
> asm("add %3,%0"
>      CC_SET(c)
>      : "=r" (z), CC_OUT(c) (carry)
>      : "0" (x), "rm" (y));
>
>
>
> I wonder if using "set" would be a performance regression over "sbb" for
> the existing bitops, in which case it would slot quite nicely into this
> scheme.
>
> I have been working in the background on a patchset for this, but as my
> life is incredibly crazy at the moment progress has been slow.  However,
> this is the way I'd like to see a patchset, with appropriate tests for
> regression in between:
>
> 1. A patchset that uses "bool" for this type of boolean outputs.
> 2. A patchset to change "sbb" to "set" where appropriate.
> 3. Introducing the above macros.
> 4. Using the macros where it makes sense.
>
> Linus also commented, quite correctly:
>
> "That said, I think we should look at actually changing some of the
> functions we use.
>
> For example, I think cmpxchg really should use ZF once we have flag
> outputs rather than comparing old and new.  That changes the whole way
> we use it.
>
> There may be other places where we might want to make those kind of
> bigger changes."
>

As long as we're thinking about this stuff, there are bunch of places 
where we use exception fixups and do awful things involving translating 
them to error codes.  Ideally they'd use as goto instead, but last time 
I checked, GCC was quite picky and didn't like output constraints and 
asm goto at the same time.  Maybe GCC could fix this at some point, but 
using condition code outputs might be reasonable, too.

Doing this would make put_user_ex and similar completely unnecessary, I 
think.

--Andy


--
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/