alsa-devel.alsa-project.org archive mirror
 help / color / mirror / Atom feed
From: Andy Shevchenko <andriy.shevchenko-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
To: Borislav Petkov <bp-l3A5Bk7waGM@public.gmane.org>,
	"Rafael J. Wysocki" <rjw-LthD3rsA81gm4RdzfppkhA@public.gmane.org>,
	Lukas Wunner <lukas-JFq808J9C/izQB+pC5nmwQ@public.gmane.org>
Cc: Andrew Morton
	<akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org>,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org>,
	Mika Westerberg
	<mika.westerberg-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>,
	alsa-devel-K7yf7f+aM1XWsZ/bQMPhNw@public.gmane.org,
	linux-input-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	kvm-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	devel-tBiZLqfeLfOHmIFyCCdPziST3g8Odh+X@public.gmane.org,
	linux-efi-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	linux-acpi-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Subject: Re: [PATCH v1 8/8] ACPI: Use recently introduced uuid_le_cmp_p{p}() helpers
Date: Thu, 27 Apr 2017 16:09:56 +0300	[thread overview]
Message-ID: <1493298596.24567.233.camel@linux.intel.com> (raw)
In-Reply-To: <20170427124631.3fycg2jbs4ffhi45-fF5Pk5pvG8Y@public.gmane.org>

On Thu, 2017-04-27 at 14:46 +0200, Borislav Petkov wrote:
> On Fri, Apr 21, 2017 at 11:22:31PM +0200, Rafael J. Wysocki wrote:
> > >  #ifdef CONFIG_ACPI_APEI_PCIEAER
> > > -		else if (!uuid_le_cmp(*(uuid_le *)gdata-
> > > >section_type,
> > > -				      CPER_SEC_PCIE)) {
> > > +		else if (!uuid_le_cmp_p(sec_type, CPER_SEC_PCIE))
> > > {
> > >  			struct cper_sec_pcie *pcie_err;
> > >  			pcie_err = (struct cper_sec_pcie
> > > *)(gdata+1);
> > >  			if (sev == GHES_SEV_RECOVERABLE &&
> > > 
> > 
> > But this one is for Boris.
> 
> I don't see anything wrong with it upon a brief inspection.

Lukas pointed to this:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68725

> 
> What could be improved here, though, is if the whole uuid_* types
> handling be changed so that gcc doesn't generate yucky code. Because
> here's what it does now, regardless of this patch:
> 
>         .file 16 "./include/linux/uuid.h"
>         .loc 16 63 0
>         leaq    16(%rsp), %rsi  #,
>         movl    $16, %edx       #,
>         movq    %r15, %rdi      # gdata,
>         movb    $84, 16(%rsp)   #, MEM[(struct  *)&u2]
>         movb    $-23, 17(%rsp)  #, MEM[(struct  *)&u2 + 1B]
>         movb    $-107, 18(%rsp) #, MEM[(struct  *)&u2 + 2B]
>         movb    $-39, 19(%rsp)  #, MEM[(struct  *)&u2 + 3B]
>         movb    $-63, 20(%rsp)  #, MEM[(struct  *)&u2 + 4B]
>         movb    $-69, 21(%rsp)  #, MEM[(struct  *)&u2 + 5B]
>         movb    $15, 22(%rsp)   #, MEM[(struct  *)&u2 + 6B]
>         movb    $67, 23(%rsp)   #, MEM[(struct  *)&u2 + 7B]
>         movb    $-83, 24(%rsp)  #, MEM[(struct  *)&u2 + 8B]
>         movb    $-111, 25(%rsp) #, MEM[(struct  *)&u2 + 9B]
>         movb    $-76, 26(%rsp)  #, MEM[(struct  *)&u2 + 10B]
>         movb    $77, 27(%rsp)   #, MEM[(struct  *)&u2 + 11B]
>         movb    $-53, 28(%rsp)  #, MEM[(struct  *)&u2 + 12B]
>         movb    $60, 29(%rsp)   #, MEM[(struct  *)&u2 + 13B]
>         movb    $111, 30(%rsp)  #, MEM[(struct  *)&u2 + 14B]
>         movb    $53, 31(%rsp)   #, MEM[(struct  *)&u2 + 15B]
>         call    memcmp  #
> 
> So it is basically building that UUID byte by byte before calling
> memcmp.
> 
> And I'm wondering if those 16-byte arrays could be replaced with
> 
> typedef struct {
>         u64 a, b;
> } u128;
> 
> from the crypto code.
> 
> And whether the code generated by gcc would look much saner. Because
> the
> CPU can handle two qwords much better/faster than 16 u8s.
> 
> Anyway, in case someone feels bored...
> 
> -- 
> Regards/Gruss,
>     Boris.
> 
> SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton,
> HRB 21284 (AG Nürnberg)

-- 
Andy Shevchenko <andriy.shevchenko-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
Intel Finland Oy

  parent reply	other threads:[~2017-04-27 13:09 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-04-21 14:46 [PATCH v1 1/8] lib/uuid: Introduce uuid_{be|le}_cmp_p{p}() helpers Andy Shevchenko
2017-04-21 14:46 ` [PATCH v1 2/8] ASoC: Intel: Skylake: Use recently introduced uuid_le_cmp_p{p}() Andy Shevchenko
2017-04-24  4:51   ` Vinod Koul
2017-04-24  8:50     ` Andy Shevchenko
2017-04-21 14:46 ` [PATCH v1 3/8] HID: intel_ish-hid: " Andy Shevchenko
2017-04-21 14:46 ` [PATCH v1 4/8] vfio-mdev: " Andy Shevchenko
2017-04-21 14:46 ` [PATCH v1 5/8] vmbus: Use recently introduced uuid_le_cmp_p{p}() helpers Andy Shevchenko
2017-04-21 14:46 ` [PATCH v1 6/8] mei: " Andy Shevchenko
2017-04-21 14:46 ` [PATCH v1 7/8] efi: " Andy Shevchenko
2017-04-21 14:46 ` [PATCH v1 8/8] ACPI: " Andy Shevchenko
2017-04-21 21:22   ` Rafael J. Wysocki
     [not found]     ` <7721821.2dV0yqi2RQ-yvgW3jdyMHm1GS7QM15AGw@public.gmane.org>
2017-04-27 12:46       ` Borislav Petkov
     [not found]         ` <20170427124631.3fycg2jbs4ffhi45-fF5Pk5pvG8Y@public.gmane.org>
2017-04-27 13:09           ` Andy Shevchenko [this message]
2017-04-27 15:00             ` Borislav Petkov
2017-04-23 10:29 ` [PATCH v1 1/8] lib/uuid: Introduce uuid_{be|le}_cmp_p{p}() helpers Winkler, Tomas
2017-04-23 12:42   ` Andy Shevchenko
     [not found]     ` <CAHp75VeTgdE=OiRNS6JrH3M-rF+jpPVgmd4G+n321=vhVE4XiA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2017-04-23 20:20       ` Winkler, Tomas
     [not found]         ` <1492975128.3570.2.camel-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
2017-04-24  8:53           ` Andy Shevchenko
     [not found]   ` <5B8DA87D05A7694D9FA63FD143655C1B543E8399-Jy8z56yoSI8MvF1YICWikbfspsVTdybXVpNB7YpNyf8@public.gmane.org>
2017-04-24 10:44     ` Lukas Wunner

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1493298596.24567.233.camel@linux.intel.com \
    --to=andriy.shevchenko-vuqaysv1563yd54fqh9/ca@public.gmane.org \
    --cc=akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org \
    --cc=alsa-devel-K7yf7f+aM1XWsZ/bQMPhNw@public.gmane.org \
    --cc=arnd-r2nGTMty4D4@public.gmane.org \
    --cc=bp-l3A5Bk7waGM@public.gmane.org \
    --cc=devel-tBiZLqfeLfOHmIFyCCdPziST3g8Odh+X@public.gmane.org \
    --cc=kvm-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=linux-acpi-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=linux-efi-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=linux-input-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=lukas-JFq808J9C/izQB+pC5nmwQ@public.gmane.org \
    --cc=mika.westerberg-VuQAYsv1563Yd54FQh9/CA@public.gmane.org \
    --cc=rjw-LthD3rsA81gm4RdzfppkhA@public.gmane.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).