linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Matthew Wilcox <willy@infradead.org>
To: Alexey Dobriyan <adobriyan@gmail.com>
Cc: torvalds@linux-foundation.org, corbet@lwn.net,
	linux-kernel@vger.kernel.org, linux-arch@vger.kernel,
	linux-doc@vger.kernel.org, x86@kernel.org
Subject: Re: [PATCH] doc: code generation style
Date: Thu, 5 Mar 2020 11:21:23 -0800	[thread overview]
Message-ID: <20200305192123.GN29971@bombadil.infradead.org> (raw)
In-Reply-To: <20200305190253.GA28787@avx2>

On Thu, Mar 05, 2020 at 10:02:53PM +0300, Alexey Dobriyan wrote:
> I wonder if it would be useful to have something like this in tree.
> 
> It states trivial things for anyone who looked at disassembly few times
> but still...

It's a bit x86-specific, and it ignores things which matter more like
paying attention to cacheline boundaries in structures.  I'm also not
convinced that those who come after us in ten years and have to widen
everything from int to long will thank us for saving a few bytes of
Icache.

> +.. code-block:: c
> +
> +        int g(int, int, flag_t);
> +        int f(int a, int b)
> +        {
> +                return g(a, b, FLAG_C);
> +        }
> +
> +Appending an argument at the end adds minimum amount of code:
> +
> +.. code-block:: none
> +
> +        f:
> +                mov     edx, FLAG_C
> +                jmp     g
> +
> +Appending an argument in the middle or in the beginning will generate
> +reshuffle sequence:
> +
> +.. code-block:: none
> +
> +        f:
> +                mov     edx, esi
> +                mov     esi, edi
> +                mov     edi, FLAG_C
> +                jmp     g

But if f is static inline, then it makes no difference at all.

> +Constants which don't fit into 12-bit window on arm will be loaded from memory
> +or constructed with 2 loads:

The 12-bit window on ARM is 8 bits rotated by a power of 4.  So for example,
0xc000003f is a valid constant, but 0x000001f7 is not.  I don't know what
arm64 does for constants.


  reply	other threads:[~2020-03-05 19:21 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-03-05 19:02 [PATCH] doc: code generation style Alexey Dobriyan
2020-03-05 19:21 ` Matthew Wilcox [this message]
2020-03-05 23:39 ` Jonathan Corbet
2020-03-06 10:40 ` Jani Nikula

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20200305192123.GN29971@bombadil.infradead.org \
    --to=willy@infradead.org \
    --cc=adobriyan@gmail.com \
    --cc=corbet@lwn.net \
    --cc=linux-arch@vger.kernel \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=torvalds@linux-foundation.org \
    --cc=x86@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).