Re: caching BLOBLISTT_SPL_HANDOFF (was Re: [PATCH] common/board_f.c: use #ifdefs a little more consistently)
Hi Rasmus,
On Fri, 28 Feb 2020 at 16:09, Rasmus Villemoes
wrote:
>
> On 28/02/2020 18.35, Tom Rini wrote:
> > On Fri, Feb 28, 2020 at 05:24:58PM +, Rasmus Villemoes wrote:
>
> >> eliminated, and there's not an #ifdef in sight.
> >
> > That sounds pretty nice actually. If you're so inclined I'd like to see
> > it.
> >
>
> So I started looking at that, and while it's mostly mechanical, one
> quickly hits the case I was worried about, some of the functions
> referring to symbols or struct members that are conditionally
> defined/declared, so there's no way around guarding such accesses at the
> preprocessor level.
>
> Case in point: I'd like to do
>
> --- a/common/board_f.c
> +++ b/common/board_f.c
> @@ -287,11 +287,9 @@ static int setup_mon_len(void)
>
> static int setup_spl_handoff(void)
> {
> -#if CONFIG_IS_ENABLED(HANDOFF)
> gd->spl_handoff = bloblist_find(BLOBLISTT_SPL_HANDOFF,
> sizeof(struct spl_handoff));
> debug("Found SPL hand-off info %p\n", gd->spl_handoff);
> -#endif
>
> return 0;
> }
> @@ -886,7 +884,7 @@ static const init_fnc_t init_sequence_f[] = {
> #ifdef CONFIG_BLOBLIST
> bloblist_init,
> #endif
> - setup_spl_handoff,
> + CONFIG_IS_ENABLED(HANDOFF) ? setup_spl_handoff : NULL,
> initf_console_record,
> #if defined(CONFIG_HAVE_FSP)
> arch_fsp_init,
>
> but that doesn't work because gd->spl_handoff only exists when
> CONFIG_IS_ENABLED(BLOBLIST) && defined(CONFIG_SPL).
>
> Now that particular one seems a bit fishy: Why is it ok to cache the
> location of the BLOBLISTT_SPL_HANDOFF blob in gd->spl_handoff? Later in
> the init sequence there's a call to reserve_bloblist, and later again
> reloc_bloblist. Doesn't that leave gd->spl_handoff stale?
Yes it does. It is only supposed to be used in the early stages of
U-Boot (proper) init.
Actually I think that member could be dropped and we could search for
it each time:
./arch/x86/cpu/broadwell/cpu_from_spl.c
>
> I'd expect that users would always have to look it up via
> bloblist_find(). Simon?
Regards,
Simon
caching BLOBLISTT_SPL_HANDOFF (was Re: [PATCH] common/board_f.c: use #ifdefs a little more consistently)
On 28/02/2020 18.35, Tom Rini wrote:
> On Fri, Feb 28, 2020 at 05:24:58PM +, Rasmus Villemoes wrote:
>> eliminated, and there's not an #ifdef in sight.
>
> That sounds pretty nice actually. If you're so inclined I'd like to see
> it.
>
So I started looking at that, and while it's mostly mechanical, one
quickly hits the case I was worried about, some of the functions
referring to symbols or struct members that are conditionally
defined/declared, so there's no way around guarding such accesses at the
preprocessor level.
Case in point: I'd like to do
--- a/common/board_f.c
+++ b/common/board_f.c
@@ -287,11 +287,9 @@ static int setup_mon_len(void)
static int setup_spl_handoff(void)
{
-#if CONFIG_IS_ENABLED(HANDOFF)
gd->spl_handoff = bloblist_find(BLOBLISTT_SPL_HANDOFF,
sizeof(struct spl_handoff));
debug("Found SPL hand-off info %p\n", gd->spl_handoff);
-#endif
return 0;
}
@@ -886,7 +884,7 @@ static const init_fnc_t init_sequence_f[] = {
#ifdef CONFIG_BLOBLIST
bloblist_init,
#endif
- setup_spl_handoff,
+ CONFIG_IS_ENABLED(HANDOFF) ? setup_spl_handoff : NULL,
initf_console_record,
#if defined(CONFIG_HAVE_FSP)
arch_fsp_init,
but that doesn't work because gd->spl_handoff only exists when
CONFIG_IS_ENABLED(BLOBLIST) && defined(CONFIG_SPL).
Now that particular one seems a bit fishy: Why is it ok to cache the
location of the BLOBLISTT_SPL_HANDOFF blob in gd->spl_handoff? Later in
the init sequence there's a call to reserve_bloblist, and later again
reloc_bloblist. Doesn't that leave gd->spl_handoff stale?
I'd expect that users would always have to look it up via
bloblist_find(). Simon?
Rasmus
Re: [PATCH] common/board_f.c: use #ifdefs a little more consistently
On Fri, Feb 28, 2020 at 05:24:58PM +, Rasmus Villemoes wrote:
> On 28/02/2020 16.46, Tom Rini wrote:
> > On Fri, Feb 28, 2020 at 08:42:21AM +, Rasmus Villemoes wrote:
> >> On 28/02/2020 00.40, Simon Glass wrote:
>
> >>> 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
>
> I'm afraid that's rather far from something that can be implemented;
> macros cannot expand to other preprocessor directives, and toupper is
> also pretty hard to do.
Darn. I would have been willing to move to reserve_FUNCTION if it would
have otherwise worked.
> What we could do if we want to reduce #ifdefs while still eliminating
> the no-op functions is to replace
>
> #ifdef CONFIG_FOO
> static int foo_init(void) {
> blabla;
> return 0;
> }
> #endif
> ...
> init_sequence_f[] = { ...
> #ifdef CONFIG_FOO
> foo_init,
> #endif
> ...
> }
>
> by
>
> static int foo_init(void) { /* always defined */
> blabla;
> return 0;
> }
>
> init_sequence_f[] = { ...
> IS_ENABLED(CONFIG_FOO) ? foo_init : NULL,
> ...
> }
>
> and teach the iterator to ignore NULL entries (I don't remember if we
> use a NULL terminator or use ARRAY_SIZE; if the former one should switch
> to the latter). It will still cost sizeof(void*) for the NULL entries,
> but the function bodies (and on powerpc the .fixups) should be
> eliminated, and there's not an #ifdef in sight.
That sounds pretty nice actually. If you're so inclined I'd like to see
it.
--
Tom
signature.asc
Description: PGP signature
Re: [PATCH] common/board_f.c: use #ifdefs a little more consistently
On 28/02/2020 16.46, Tom Rini wrote:
> On Fri, Feb 28, 2020 at 08:42:21AM +, Rasmus Villemoes wrote:
>> On 28/02/2020 00.40, Simon Glass wrote:
>>> 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
I'm afraid that's rather far from something that can be implemented;
macros cannot expand to other preprocessor directives, and toupper is
also pretty hard to do.
What we could do if we want to reduce #ifdefs while still eliminating
the no-op functions is to replace
#ifdef CONFIG_FOO
static int foo_init(void) {
blabla;
return 0;
}
#endif
...
init_sequence_f[] = { ...
#ifdef CONFIG_FOO
foo_init,
#endif
...
}
by
static int foo_init(void) { /* always defined */
blabla;
return 0;
}
init_sequence_f[] = { ...
IS_ENABLED(CONFIG_FOO) ? foo_init : NULL,
...
}
and teach the iterator to ignore NULL entries (I don't remember if we
use a NULL terminator or use ARRAY_SIZE; if the former one should switch
to the latter). It will still cost sizeof(void*) for the NULL entries,
but the function bodies (and on powerpc the .fixups) should be
eliminated, and there's not an #ifdef in sight.
If one also wants to get rid of those NULL entries, I did
https://lore.kernel.org/lkml/1444165543-2209-1-git-send-email-li...@rasmusvillemoes.dk/
a long time ago (see the COND_INITIALIZER()), but whether that can be
tweaked to still automatically avoid a "defined but not used" warning I
don't know.
> And then a little harder thinking about negative-case (OF_EMBED) ? Or
> just have those be the few ifndef's?
That can be done in the same manner by just switching second and third
operand.
The problem is the function bodies which rely on symbols (for example
CONFIG_* values) that only exist if CONFIG_FOO.
Rasmus
Re: [PATCH] common/board_f.c: use #ifdefs a little more consistently
On Fri, Feb 28, 2020 at 08:42:21AM +, Rasmus Villemoes wrote: > On 28/02/2020 00.40, Simon Glass wrote: > > Hi Rasmus, > > > > On Thu, 27 Feb 2020 at 00:18, Rasmus Villemoes > > 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 signature.asc Description: PGP signature
Re: [PATCH] common/board_f.c: use #ifdefs a little more consistently
On 28/02/2020 00.40, Simon Glass wrote: > Hi Rasmus, > > On Thu, 27 Feb 2020 at 00:18, Rasmus Villemoes > 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. Rasmus
Re: [PATCH] common/board_f.c: use #ifdefs a little more consistently
Hi Rasmus, On Thu, 27 Feb 2020 at 00:18, Rasmus Villemoes 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? The reason I ask is that it inlines those function calls in the normal case, at least from my inspection. Using if() is preferable to #if if there is no cost. > > Signed-off-by: Rasmus Villemoes > --- > common/board_f.c | 54 > 1 file changed, 36 insertions(+), 18 deletions(-) Regards, Simon
