All of lore.kernel.org
 help / color / mirror / Atom feed
From: Tom Rini <trini@konsulko.com>
To: u-boot@lists.denx.de
Subject: [PATCH] common/board_f.c: use #ifdefs a little more consistently
Date: Fri, 28 Feb 2020 10:46:20 -0500	[thread overview]
Message-ID: <20200228154620.GJ18302@bill-the-cat> (raw)
In-Reply-To: <76d3bc74-0406-cd11-8793-b2192ffdb7ee@prevas.dk>

On Fri, Feb 28, 2020 at 08:42:21AM +0000, Rasmus Villemoes wrote:
> On 28/02/2020 00.40, Simon Glass wrote:
> > Hi Rasmus,
> > 
> > On Thu, 27 Feb 2020 at 00:18, Rasmus Villemoes
> > <rasmus.villemoes@prevas.dk> wrote:
> >>
> >> Some init functions, e.g. print_resetinfo(), are conditionally defined
> >> depending on some config options, and are correspondingly
> >> conditionally included in the init_sequence_f[] array.
> >>
> >> Others are unconditionally defined and included in init_sequence_f[],
> >> but have their entire body, sans a mandatory "return 0", conditionally
> >> compiled.
> >>
> >> For the simple cases, switch to the former model, making it a bit more
> >> consistent. This also makes the U-Boot image very slightly smaller and
> >> avoids a few useless calls to no-op functions during board_init_f.
> > 
> > Can you check if it definitely does change the size? 
> 
> It does, I did build to see how much. On ppc, it's 8 bytes per no-op
> function (one "put 0 in r3", one blr instruction), plus 4 bytes for the
> array entry, plus 4 bytes for a .fixup entry - in my case ending up with
> 7*16=112, because all but the #ifndef CONFIG_OF_EMBED applied.
> 
> The reason I ask
> > is that it inlines those function calls in the normal case, at least
> > from my inspection.
> 
> The compiler can't inline and thus eliminate these as they are not
> called directly, but their addresses are used to populate the
> init_sequence_f[] array and called through that.
> 
> > Using if() is preferable to #if if there is no cost.
> 
> Completely agree, and I also prefer to have the linker eliminate unused
> functions rather than cluttering the C code with #ifdefs. But that can't
> be used in this case.
> 
> Anyway, this wasn't primarily to save 112 bytes or whatnot from the
> U-Boot image, just to use one style a little more consistently.

Perhaps we could come up with a little more macro-magic?  In
psuedo-code:
#define RESERVE_INIT_SEQ_F_ENTRY(fn) \
#if CONFIG_IS_ENABLED(toupper(fn))
reserve_##fn
#endif
#endif

And then a little harder thinking about negative-case (OF_EMBED) ?  Or
just have those be the few ifndef's?

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 659 bytes
Desc: not available
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20200228/0e4c7bb6/attachment.sig>

  reply	other threads:[~2020-02-28 15:46 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-02-27  8:18 [PATCH] common/board_f.c: use #ifdefs a little more consistently Rasmus Villemoes
2020-02-27 23:40 ` Simon Glass
2020-02-28  8:42   ` Rasmus Villemoes
2020-02-28 15:46     ` Tom Rini [this message]
2020-02-28 17:24       ` Rasmus Villemoes
2020-02-28 17:35         ` Tom Rini
2020-02-28 23:09           ` caching BLOBLISTT_SPL_HANDOFF (was Re: [PATCH] common/board_f.c: use #ifdefs a little more consistently) Rasmus Villemoes
2020-03-02 19:47             ` Simon Glass
2020-03-02 20:01               ` caching BLOBLISTT_SPL_HANDOFF Rasmus Villemoes
2020-03-04 23:11                 ` Simon Glass

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=20200228154620.GJ18302@bill-the-cat \
    --to=trini@konsulko.com \
    --cc=u-boot@lists.denx.de \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.