[PATCH] x86: Simplify calls to cpuid by using + for in/out constraints

[PATCH] x86: Simplify calls to cpuid by using + for in/out constraints

[Josh Triplett]

Signed-off-by: Josh Triplett <josh@joshtriplett.org>
---

Build-tested only.

 arch/x86/include/asm/processor.h |    7 +++----
 arch/x86/xen/enlighten.c         |    7 +++----
 2 files changed, 6 insertions(+), 8 deletions(-)

diff --git a/arch/x86/include/asm/processor.h b/arch/x86/include/asm/processor.h
index c776826..dfa947e 100644
--- a/arch/x86/include/asm/processor.h
+++ b/arch/x86/include/asm/processor.h
@@ -180,11 +180,10 @@ static inline void native_cpuid(unsigned int *eax, unsigned int *ebx,
 {
 	/* ecx is often an input as well as an output. */
 	asm("cpuid"
-	    : "=a" (*eax),
+	    : "+a" (*eax),
 	      "=b" (*ebx),
-	      "=c" (*ecx),
-	      "=d" (*edx)
-	    : "0" (*eax), "2" (*ecx));
+	      "+c" (*ecx),
+	      "=d" (*edx));
 }
 
 static inline void load_cr3(pgd_t *pgdir)
diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
index 6ee2ef8..6eab164 100644
--- a/arch/x86/xen/enlighten.c
+++ b/arch/x86/xen/enlighten.c
@@ -190,11 +190,10 @@ static void xen_cpuid(unsigned int *ax, unsigned int *bx,
 	}
 
 	asm(XEN_EMULATE_PREFIX "cpuid"
-		: "=a" (*ax),
+		: "+a" (*ax),
 		  "=b" (*bx),
-		  "=c" (*cx),
-		  "=d" (*dx)
-		: "0" (*ax), "2" (*cx));
+		  "+c" (*cx),
+		  "=d" (*dx));
 
 	*cx &= maskecx;
 	*dx &= maskedx;
-- 
1.5.6.5

Re: [PATCH] x86: Simplify calls to cpuid by using + for in/out constraints

[H. Peter Anvin]

I would prefer to not apply this patch unless there is a good reason.
The existing code isn't broken, and any time we change an asm()
statement we risk triggering bugs in some obscure gcc version.

It isn't, of course, that the proposed change is wrong, but simply that
it is an unnecessary change, and since it involves asm() statements I
would like to reject it for churn reduction reasons.  Especially so
since it is "build-tested only".

	-hpa


On 08/08/2009 01:21 PM, Josh Triplett wrote:
> Signed-off-by: Josh Triplett <josh@joshtriplett.org>
> ---
> 
> Build-tested only.
> 
>  arch/x86/include/asm/processor.h |    7 +++----
>  arch/x86/xen/enlighten.c         |    7 +++----
>  2 files changed, 6 insertions(+), 8 deletions(-)
> 
> diff --git a/arch/x86/include/asm/processor.h b/arch/x86/include/asm/processor.h
> index c776826..dfa947e 100644
> --- a/arch/x86/include/asm/processor.h
> +++ b/arch/x86/include/asm/processor.h
> @@ -180,11 +180,10 @@ static inline void native_cpuid(unsigned int *eax, unsigned int *ebx,
>  {
>  	/* ecx is often an input as well as an output. */
>  	asm("cpuid"
> -	    : "=a" (*eax),
> +	    : "+a" (*eax),
>  	      "=b" (*ebx),
> -	      "=c" (*ecx),
> -	      "=d" (*edx)
> -	    : "0" (*eax), "2" (*ecx));
> +	      "+c" (*ecx),
> +	      "=d" (*edx));
>  }
>  
>  static inline void load_cr3(pgd_t *pgdir)
> diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
> index 6ee2ef8..6eab164 100644
> --- a/arch/x86/xen/enlighten.c
> +++ b/arch/x86/xen/enlighten.c
> @@ -190,11 +190,10 @@ static void xen_cpuid(unsigned int *ax, unsigned int *bx,
>  	}
>  
>  	asm(XEN_EMULATE_PREFIX "cpuid"
> -		: "=a" (*ax),
> +		: "+a" (*ax),
>  		  "=b" (*bx),
> -		  "=c" (*cx),
> -		  "=d" (*dx)
> -		: "0" (*ax), "2" (*cx));
> +		  "+c" (*cx),
> +		  "=d" (*dx));
>  
>  	*cx &= maskecx;
>  	*dx &= maskedx;

Re: [PATCH] x86: Simplify calls to cpuid by using + for in/out constraints

[Josh Triplett]

On Sun, Aug 09, 2009 at 10:19:13AM -0700, H. Peter Anvin wrote:
> I would prefer to not apply this patch unless there is a good reason.
> The existing code isn't broken, and any time we change an asm()
> statement we risk triggering bugs in some obscure gcc version.

Fair enough.

> It isn't, of course, that the proposed change is wrong, but simply that
> it is an unnecessary change, and since it involves asm() statements I
> would like to reject it for churn reduction reasons.  Especially so
> since it is "build-tested only".

Given the risk of "bugs in some obscure gcc version", it doesn't seem
like running it or even comparing for identical code would validate
anything more than the correctness of the gcc version currently in use.

- Josh triplett