similar to: [PATCH v2 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 >

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:

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

* Nadav Amit <namit at vmware.com> wrote: > > I ran some limited number of benchmarks, and in general the performance > > impact is not very notable. You can still see >10 cycles shaved off some > > syscalls that manipulate page-tables (e.g., mprotect()), in which > > paravirt caused many functions not to be inlined. In addition this > > patch-set can

* 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

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

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

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

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

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:

On Mon, 2 Jul 2007, David A. Greene wrote: >>> - Changing the API >>> a) Template it to take two iterators. This causes code size bloat. > > This seems like the right solution to me. Unless llvm is running on > extremely limited memory embedded systems, the extra code space > shouldn't be an issue. Code size is always an issue. What specifically are you

On 12/06/18 13:50, Nadav Amit wrote: > GCC considers the number of statements in inlined assembly blocks, > according to new-lines and semicolons, as an indication to the cost of > the block in time and space. This data is distorted by the kernel code, > which puts information in alternative sections. As a result, the > compiler may perform incorrect inlining and branch

On Monday 02 July 2007 16:26, Chris Lattner wrote: > On Sun, 1 Jul 2007, Nick Lewycky wrote: > > I've been running LLVM with _GLIBCXX_DEBUG (extra checks) turned on to > > see what would happen, and it's been a complete disaster. Well, that's a bit harsh, isn't it? It's finding bugs, just like it's supposed to. :) I believe I've started to run into

FYI there is now serious talk of the Linux kernel dropping support for compilers that *don't* support asm goto. On Tue, 2017-04-04 at 13:13 -0700, Matthias Braun via llvm-dev wrote: > > > On Apr 4, 2017, at 11:44 AM, John McCall via llvm-dev > > ts.llvm.org> wrote: > > > > > On Apr 4, 2017, at 2:12 PM, Matthias Braun <matze at braunis.de> > >

On Tue, 2017-04-04 at 16:26 +0000, Chandler Carruth via llvm-dev wrote: > On Tue, Apr 4, 2017 at 6:07 AM Yatsina, Marina via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Asm goto feature was introduces to GCC in order to optimize the > > support for tracepoints in Linux kernel (it can be used for other > > things that do nop patching). > >   > > GCC

Linux kernel is using the “asm goto” feature, other projects probably use it as well. I think it provides motivation to support it in LLVM. Regarding the complexity, I believe there is some infrastructure that we can at least partially reuse (the support for “indirectbr” instruction). My focus is adding “asm goto” support, the other things are indeed completely orthogonal and came up in bugs

Hi, I wanted to revive this issue of supporting asm goto (Bug 9295<https://bugs.llvm.org/show_bug.cgi?id=9295>). As was already proposed, the best way seems to be introducing new IR. If we're changing the IR, we should probably provide an infrastructure that solves or at least enables future support for things like: 1. MS-style inline asm jmps and goto (Bug

> On Apr 4, 2017, at 11:44 AM, John McCall via llvm-dev <llvm-dev at lists.llvm.org> wrote: > >> On Apr 4, 2017, at 2:12 PM, Matthias Braun <matze at braunis.de <mailto:matze at braunis.de>> wrote: >> My two cents: >> >> - I think inline assembly should work even if the compiler cannot parse the contents. This would rule out msvc inline assembly