Received: by 2002:ac0:a582:0:0:0:0:0 with SMTP id m2-v6csp3157894imm; Sun, 14 Oct 2018 13:03:32 -0700 (PDT) X-Google-Smtp-Source: ACcGV62CAt5rUzmR/A6Rml1QdtcZP8HRFW1FJprCBpEPhRgE27TusQgMVf3PK3+h/ZM7TXWXmSRx X-Received: by 2002:a62:c186:: with SMTP id i128-v6mr14712111pfg.248.1539547412910; Sun, 14 Oct 2018 13:03:32 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1539547412; cv=none; d=google.com; s=arc-20160816; b=ogLi1xo5S5Byrs7GNQD+kcVJYjF7HznrQrShpKs4BqNCXntCDi1omAx2GlIdRISFi5 9pBWva9huTiiY8RWq6ZM5rNIhuM5k4Pq2bMRFmWEYlw5POm4/RE9SQ6KJ1Qq6BSsK6R+ AeypphIioIoGa56Z7uNipU8QsxQy+k4NtYVwlWZPz+uBXjwLROv+5J3o3DOoVQpkiPl3 KnJJr9pg2ezZYfkVeh2EGWwK1I65bPzag83/pKbfA8F10uFHJvmQNOIL/tX196ne9Vui qJFM/DYo4YfyQKmBA14wY7X+tGMwGMXrK/ymkWBP5CBdNvep5N6PrqUYMKKK7rBuDyu9 rJSg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=yRxDt7pPggiQ9oJ2tDEon5D24LTXLpBABfsexC/DQrI=; b=U1ag1hB6rVMJukN2jpUzdSnHDxTONRpLEgVmUxE63O73CgRBaYGfhqfhuKjFnUyc93 gWcb8On+C861RgJ79U12LfoKKVQAKZsaUUAH8YjdYh/GJjPgBm7ZwRnimIKxfVyyDVsy shtjFB77kG08kA9wKhw1U7yA0v3BgG6BCzNgruNcSIyeYrMLmQMnN35Xc4FcfuDZ3MHN EPmjfv+Lnm9/lpFAdSp0bZpPx9Lxd9K+m7YdIPCpmlA8shFPcdL6kOypCXqMCO9XC2Fj 2iojzJYGnJv2wAgJXKr/GCvwnHJuQj0nwa55SnhNO8ManE5GkZkTuhmU9I0DFAqkJ4t8 phww== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id 3-v6si8093448pgi.473.2018.10.14.13.03.15; Sun, 14 Oct 2018 13:03:32 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726595AbeJODpB (ORCPT + 99 others); Sun, 14 Oct 2018 23:45:01 -0400 Received: from mail.skyhub.de ([5.9.137.197]:49916 "EHLO mail.skyhub.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726431AbeJODpB (ORCPT ); Sun, 14 Oct 2018 23:45:01 -0400 X-Virus-Scanned: Nedap ESD1 at mail.skyhub.de Received: from mail.skyhub.de ([127.0.0.1]) by localhost (blast.alien8.de [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id SGPal5CobBuT; Sun, 14 Oct 2018 22:02:52 +0200 (CEST) Received: from zn.tnic (p200300EC2BDC0500329C23FFFEA6A903.dip0.t-ipconnect.de [IPv6:2003:ec:2bdc:500:329c:23ff:fea6:a903]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.skyhub.de (SuperMail on ZX Spectrum 128k) with ESMTPSA id 970701EC0987; Sun, 14 Oct 2018 22:02:52 +0200 (CEST) Date: Sun, 14 Oct 2018 22:02:41 +0200 From: Borislav Petkov To: Uros Bizjak Cc: x86@kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] x86: Use assembly instruction mnemonics instead of .byte streams in arch_hweight.h Message-ID: <20181014200241.GD7667@zn.tnic> References: <20181014183510.18908-1-ubizjak@gmail.com> <20181014184735.GC7667@zn.tnic> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sun, Oct 14, 2018 at 09:15:00PM +0200, Uros Bizjak wrote: > The ChangeLog says "real INSTRUCTION mnemonics", e.g. POPCNTQ and POPCNTL. Right, INSTRUCTION. > The compiler will generate the register name with the correct implied > width (e.g. %rax for long, %eax for int), so the assembler will be > able to cross check if operands fit the instruction The __arch_hweightXX functions already enforce the proper type and the inline asm() operands already place the arguments in the proper registers where the instruction encoding expects them. So if you're going to relax this, then you could relax the inline asm operand specifications too. I say you "could" because then you need to fix arch/x86/lib/hweight.S too, which would be at least ugly. So I think we're stuck with %xDI/xAX and %xAX as operands, where 'x' is either 'r' or 'e'. > And there will be a couple of ugly #defines less. That's the only advantage of this change AFAICT. How about you reflect that in your commit message? Thx. -- Regards/Gruss, Boris. Good mailing practices for 400: avoid top-posting and trim the reply.