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
WARNING: multiple messages have this Message-ID (diff)
From: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
To: Borislav Petkov <bp@suse.de>,
"Rafael J. Wysocki" <rjw@rjwysocki.net>,
Lukas Wunner <lukas@wunner.de>
Cc: Andrew Morton <akpm@linux-foundation.org>,
linux-kernel@vger.kernel.org, Arnd Bergmann <arnd@arndb.de>,
Mika Westerberg <mika.westerberg@linux.intel.com>,
alsa-devel@alsa-project.org, linux-input@vger.kernel.org,
kvm@vger.kernel.org, devel@linuxdriverproject.org,
linux-efi@vger.kernel.org, linux-acpi@vger.kernel.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@pd.tnic>
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@linux.intel.com>
Intel Finland Oy
next prev parent reply other threads:[~2017-04-27 13:09 UTC|newest]
Thread overview: 37+ 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 ` 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-21 14:46 ` Andy Shevchenko
2017-04-24 4:51 ` Vinod Koul
2017-04-24 8:50 ` Andy Shevchenko
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 ` Andy Shevchenko
2017-04-21 14:46 ` [PATCH v1 4/8] vfio-mdev: " Andy Shevchenko
2017-04-21 14:46 ` 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 ` Andy Shevchenko
2017-04-21 14:46 ` [PATCH v1 6/8] mei: " Andy Shevchenko
2017-04-21 14:46 ` Andy Shevchenko
2017-04-21 14:46 ` [PATCH v1 7/8] efi: " Andy Shevchenko
2017-04-21 14:46 ` 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
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 13:09 ` Andy Shevchenko
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
2017-04-23 12:42 ` Andy Shevchenko
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
2017-04-23 20:20 ` Winkler, Tomas
2017-04-23 20:20 ` Winkler, Tomas
[not found] ` <1492975128.3570.2.camel-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
2017-04-24 8:53 ` Andy Shevchenko
2017-04-24 8:53 ` Andy Shevchenko
2017-04-24 8:53 ` Andy Shevchenko
[not found] ` <5B8DA87D05A7694D9FA63FD143655C1B543E8399-Jy8z56yoSI8MvF1YICWikbfspsVTdybXVpNB7YpNyf8@public.gmane.org>
2017-04-24 10:44 ` Lukas Wunner
2017-04-24 10:44 ` Lukas Wunner
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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.