similar to: [kbuild ack?] Re: [PATCH v6 0/9] x86: macrofying inline asm for better compilation

On Tue, Sep 18, 2018 at 2:28 PM, Nadav Amit <namit at vmware.com> wrote: > This patch-set deals with an interesting yet stupid problem: kernel code > that does not get inlined despite its simplicity. There are several > causes for this behavior: "cold" attribute on __init, different function > optimization levels; conditional constant computations based on >

On Wed, Dec 19, 2018 at 5:26 AM Nadav Amit <namit at vmware.com> wrote: > > > On Dec 17, 2018, at 8:03 AM, Masahiro Yamada <yamada.masahiro at socionext.com> wrote: > > > > This series reverts the in-kernel workarounds for inlining issues. > > > > The commit description of 77b0bf55bc67 mentioned > > "We also hope that GCC will eventually get

* Nadav Amit <namit at vmware.com> wrote: > Ping. Masahiro Yamada noted that some Reviewed-by tags were not added - could you please double check past mails and add them and re-send against the latest kernel? Thanks, Ingo

On Sun, Dec 16, 2018 at 12:29 PM Nadav Amit <namit at vmware.com> wrote: > > > On Dec 15, 2018, at 6:50 PM, Masahiro Yamada <yamada.masahiro at socionext.com> wrote: > > > > Revert the following 9 commits: > > > > [1] 5bdcd510c2ac ("x86/jump-labels: Macrofy inline assembly code to > > work around GCC inlining bugs") > > >

* Masahiro Yamada <yamada.masahiro at socionext.com> wrote: > This series reverts the in-kernel workarounds for inlining issues. > > The commit description of 77b0bf55bc67 mentioned > "We also hope that GCC will eventually get fixed,..." > > Now, GCC provides a solution. > > https://gcc.gnu.org/onlinedocs/gcc/Extended-Asm.html > explains the new

Hi people, this is an attempt to see whether gcc's inline asm heuristic when estimating inline asm statements' cost for better inlining can be improved. AFAIU, the problematic arises when one ends up using a lot of inline asm statements in the kernel but due to the inline asm cost estimation heuristic which counts lines, I think, for example like in this here macro:

Revert the following 9 commits: [1] 5bdcd510c2ac ("x86/jump-labels: Macrofy inline assembly code to work around GCC inlining bugs") This was partially reverted because it made good cleanups irrespective of the inlining issue; the error message is still unneeded, and the conversion to STATIC_BRANCH_{NOP,JUMP} should be kept. [2] d5a581d84ae6 ("x86/cpufeature:

This series reverts the in-kernel workarounds for inlining issues. The commit description of 77b0bf55bc67 mentioned "We also hope that GCC will eventually get fixed,..." Now, GCC provides a solution. https://gcc.gnu.org/onlinedocs/gcc/Extended-Asm.html explains the new "asm inline" syntax. The performance issue will be eventually solved. [About Code cleanups] I know Nadam

This series reverts the in-kernel workarounds for inlining issues. The commit description of 77b0bf55bc67 mentioned "We also hope that GCC will eventually get fixed,..." Now, GCC provides a solution. https://gcc.gnu.org/onlinedocs/gcc/Extended-Asm.html explains the new "asm inline" syntax. The performance issue will be eventually solved. [About Code cleanups] I know Nadam

On Tue, Jun 19, 2018 at 12:48:45PM -0700, Nadav Amit wrote: > Nadav Amit (9): > Makefile: Prepare for using macros for inline asm > x86: objtool: use asm macro for better compiler decisions > x86: refcount: prevent gcc distortions > x86: alternatives: macrofy locks for better inlining > x86: bug: prevent gcc distortions > x86: prevent inline distortion by paravirt

On Mon, Jun 04, 2018 at 04:21:22AM -0700, Nadav Amit wrote: > This patch-set deals with an interesting yet stupid problem: kernel code > that does not get inlined despite its simplicity. There are several > causes for this behavior: "cold" attribute on __init, different function > optimization levels; conditional constant computations based on > __builtin_constant_p(); and

From: Nadav Amit > Sent: 17 May 2018 17:14 > This patch-set deals with an interesting yet stupid problem: kernel code > that does not get inlined despite its simplicity. There are several > causes for this behavior: "cold" attribute on __init, different function > optimization levels; conditional constant computations based on > __builtin_constant_p(); and finally large

Revert the following commits: - 5bdcd510c2ac9efaf55c4cbd8d46421d8e2320cd ("x86/jump-labels: Macrofy inline assembly code to work around GCC inlining bugs") - d5a581d84ae6b8a4a740464b80d8d9cf1e7947b2 ("x86/cpufeature: Macrofy inline assembly code to work around GCC inlining bugs") - 0474d5d9d2f7f3b11262f7bf87d0e7314ead9200. ("x86/extable: Macrofy inline assembly

Revert the following commits: - 5bdcd510c2ac9efaf55c4cbd8d46421d8e2320cd ("x86/jump-labels: Macrofy inline assembly code to work around GCC inlining bugs") - d5a581d84ae6b8a4a740464b80d8d9cf1e7947b2 ("x86/cpufeature: Macrofy inline assembly code to work around GCC inlining bugs") - 0474d5d9d2f7f3b11262f7bf87d0e7314ead9200. ("x86/extable: Macrofy inline assembly

Hi. On Wed, Oct 10, 2018 at 1:14 AM Segher Boessenkool <segher at kernel.crashing.org> wrote: > > On Mon, Oct 08, 2018 at 11:07:46AM +0200, Richard Biener wrote: > > On Mon, 8 Oct 2018, Segher Boessenkool wrote: > > > On Sun, Oct 07, 2018 at 03:53:26PM +0000, Michael Matz wrote: > > > > On Sun, 7 Oct 2018, Segher Boessenkool wrote: > > > > >

Hi. On Wed, Oct 10, 2018 at 1:14 AM Segher Boessenkool <segher at kernel.crashing.org> wrote: > > On Mon, Oct 08, 2018 at 11:07:46AM +0200, Richard Biener wrote: > > On Mon, 8 Oct 2018, Segher Boessenkool wrote: > > > On Sun, Oct 07, 2018 at 03:53:26PM +0000, Michael Matz wrote: > > > > On Sun, 7 Oct 2018, Segher Boessenkool wrote: > > > > >

Hi Segher, On Sun, Dec 2, 2018 at 3:48 PM Segher Boessenkool <segher at kernel.crashing.org> wrote: > > On Fri, Nov 30, 2018 at 10:06:02AM +0100, Boris Petkov wrote: > > On November 29, 2018 1:25:02 PM GMT+01:00, Segher Boessenkool <segher at kernel.crashing.org> wrote: > > >This will only be fixed from GCC 9 on, if the compiler adopts it. The > >

Hi Peter, On Wed, Oct 31, 2018 at 9:58 PM Peter Zijlstra <peterz at infradead.org> wrote: > > On Sat, Oct 13, 2018 at 09:33:35PM +0200, Borislav Petkov wrote: > > Ok, > > > > with Segher's help I've been playing with his patch ontop of bleeding > > edge gcc 9 and here are my observations. Please double-check me for > > booboos so that they can be

Daniel, drm-misc-next-fixes? Dave. On Fri, 26 Apr 2019 at 12:25, <yamada.masahiro at socionext.com> wrote: > > Hi Dave, > > > -----Original Message----- > > From: Dave Airlie [mailto:airlied at gmail.com] > > Sent: Friday, April 26, 2019 11:19 AM > > To: Yamada, Masahiro/山田 真弘 <yamada.masahiro at socionext.com> > > Cc: David Airlie <airlied

From: Arnd Bergmann <arnd at arndb.de> This is a follow-up on a couple of patch series I sent in the past, enabling -Wextra (aside from stuff that is explicitly disabled), -Wcast-function-pointer-strict and -Wrestrict. I have tested these on 'defconfig' and 'allmodconfig' builds across all architectures, as well as many 'randconfig' builds on x86, arm and arm64. It