similar to: [PATCH 0/6] Macrofying inline assembly for better compilation

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

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 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

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

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 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:

Pierre Habouzit wrote: > [ please CC: me as I'm not subscribed ] > > On Wed, Mar 11, 2009 at 04:13:34AM +0000, bugzilla-daemon at cs.uiuc.edu wrote: >> http://llvm.org/bugs/show_bug.cgi?id=3756 >> >> Chris Lattner <clattner at apple.com> changed: >> >> What |Removed |Added >>

Dan Gohman wrote: > On Mar 15, 2009, at 6:16 PM, Nick Lewycky wrote: > >> Pierre Habouzit wrote: >>> [ please CC: me as I'm not subscribed ] >>> >>> On Wed, Mar 11, 2009 at 04:13:34AM +0000, bugzilla- >>> daemon at cs.uiuc.edu wrote: >>>> http://llvm.org/bugs/show_bug.cgi?id=3756 >>>> >>>> Chris Lattner

On Mar 15, 2009, at 6:16 PM, Nick Lewycky wrote: > Pierre Habouzit wrote: >> [ please CC: me as I'm not subscribed ] >> >> On Wed, Mar 11, 2009 at 04:13:34AM +0000, bugzilla- >> daemon at cs.uiuc.edu wrote: >>> http://llvm.org/bugs/show_bug.cgi?id=3756 >>> >>> Chris Lattner <clattner at apple.com> changed: >>> >>>

[ please CC: me as I'm not subscribed ] On Wed, Mar 11, 2009 at 04:13:34AM +0000, bugzilla-daemon at cs.uiuc.edu wrote: > http://llvm.org/bugs/show_bug.cgi?id=3756 > > Chris Lattner <clattner at apple.com> changed: > > What |Removed |Added > ---------------------------------------------------------------------------- >

On Thu, 2018-06-07 at 11:32 -0700, Nick Desaulniers wrote: > Functions marked extern inline do not emit an externally visible > function when the gnu89 C standard is used. Some KBUILD Makefiles > overwrite KBUILD_CFLAGS. This is an issue for GCC 5.1+ users as without > an explicit C standard specified, the default is gnu11. Since c99, the > semantics of extern inline have changed

I actually was working on an updated patch for the LLVM-side of this, also. :) I was just working on some test cases; I'll post it soon. It's somewhat different than yours. I haven't touched the clang side yet, but I think it needs to be more complex than what you have there. I think it actually needs to be able to evaluate the intrinsic as a constant _false_ in the front-end in some

Hello again! I took a stab at PR4898[1]. The attached patch improves Clang's __builtin_constant_p support so that the Linux kernel is happy. With this improvement, Clang can determine if __builtin_constant_p is true or false after inlining. As an example: static __attribute__((always_inline)) int foo(int x) { if (__builtin_constant_p(x)) return 1; return 0; } static

4.4-stable review patch. If anyone has any objections, please let me know. ------------------ From: Nick Desaulniers <ndesaulniers at google.com> commit d03db2bc26f0e4a6849ad649a09c9c73fccdc656 upstream. Functions marked extern inline do not emit an externally visible function when the gnu89 C standard is used. Some KBUILD Makefiles overwrite KBUILD_CFLAGS. This is an issue for GCC 5.1+