lkml.org 
[lkml]   [2018]   [Nov]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    Date
    SubjectRe: PROPOSAL: Extend inline asm syntax with size spec
    Hi.


    On Wed, Oct 10, 2018 at 1:14 AM Segher Boessenkool
    <segher@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:
    > > > > > On Sun, Oct 07, 2018 at 11:18:06AM +0200, Borislav Petkov wrote:
    > > > > > > Now, Richard suggested doing something like:
    > > > > > >
    > > > > > > 1) inline asm ("...")
    > > > > >
    > > > > > What would the semantics of this be?
    > > > >
    > > > > The size of the inline asm wouldn't be counted towards the inliner size
    > > > > limits (or be counted as "1").
    > > >
    > > > That sounds like a good option.
    > >
    > > Yes, I also like it for simplicity. It also avoids the requirement
    > > of translating the number (in bytes?) given by the user to
    > > "number of GIMPLE instructions" as needed by the inliner.
    >
    > This patch implements this, for C only so far. And the syntax is
    > "asm inline", which is more in line with other syntax.
    >
    > How does this look?


    Thank you very much for your work.


    https://gcc.gnu.org/ml/gcc-patches/2018-10/msg01932.html

    How is the progress of this in GCC ML?



    I am really hoping the issue will be solved by compiler
    instead of the in-kernel workaround.


    Since commit 77b0bf55bc675233d22cd5df97605d516d64525e,
    DISTCC breakage was reported.


    Then, another problem showed up.

    Debian linux-headers package is broken
    due to missing arch/x86/kernel/macros.s

    https://www.spinics.net/lists/linux-kbuild/msg20037.html

    The kernel-devel RPM package is broken as well.

    More fundamentally, the external module building itself is broken;
    'make clean' must keep all files needed for external modules, but
    *.s files are all gone.


    Of course, we can fix the problems at the cost of uglifying Makefiles.
    I wrote a patch to fix the external module building
    and packages, and now have it in hand locally.


    But, I'd like to ask if x86 people want to keep this macros.s approach.
    Revert 77b0bf55bc675 right now
    assuming the compiler will eventually solve the issue?

    Do you have ideas? Comments?


    --
    Best Regards
    Masahiro Yamada

    \
     
     \ /
      Last update: 2018-11-29 12:48    [W:6.608 / U:0.008 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site