search for: macrofying

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

......" 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 Amit is opposed to the full revert. He also claims his motivation for macrofying was not only performance, but also cleanups. IIUC, the criticism addresses the code duplication between C and ASM. If so, I'd like to suggest a different approach for cleanups. Please see the last 3 patches. IMHO, preprocessor approach is more straight-forward, and readable. Basically, this i...

......" 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 Amit is opposed to the full revert. He also claims his motivation for macrofying was not only performance, but also cleanups. IIUC, the criticism addresses the code duplication between C and ASM. If so, I'd like to suggest a different approach for cleanups. Please see the last 3 patches. IMHO, preprocessor approach is more straight-forward, and readable. Basically, this i...

...; 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 Amit is opposed to the full revert. > He also claims his motivation for macrofying was not only > performance, but also cleanups. > > IIUC, the criticism addresses the code duplication between C and ASM. > > If so, I'd like to suggest a different approach for cleanups. > Please see the last 3 patches. > IMHO, preprocessor approach is more straight-forwa...

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

...solved. > > > > [About Code cleanups] > > > > I know Nadam Amit is opposed to the full revert. > > My name is Nadav. Sorry about that. (I relied on a spell checker. I should be careful about typos in people's name.) > > He also claims his motivation for macrofying was not only > > performance, but also cleanups. > > Masahiro, I understand your concerns and criticism, and indeed various > alternative solutions exist. I do have my reservations about the one you > propose, since it makes coding more complicated to simplify the Make system. &gt...

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

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

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:

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

...to improve: [auto build test ERROR on linus/master] [also build test ERROR on v4.18-rc1 next-20180619] [cannot apply to tip/x86/core] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Nadav-Amit/x86-macrofying-inline-asm-for-better-compilation/20180620-112043 config: i386-randconfig-x016-201824 (attached as .config) compiler: gcc-7 (Debian 7.3.0-16) 7.3.0 reproduce: # save the attached .config to linux build tree make ARCH=i386 All errors (new ones prefixed by >>): arch/x86/in...

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:

Hi, To to build an RPM from the nut 2.0.3 source I've corrected the old nut.spec.in file. Please find a copy of the slightly updated spec file attached. The changes are documented at the bottom of the spec file. Regards, Will -------------- next part -------------- # don't know how different I can do this %define majorver 2.0 %define version 2.0.3 %define relver 1 %define nutuser