On Thu, 1 Oct 2020 03:53:23 +0200 Andrew Lunn wrote:
> On Wed, Sep 30, 2020 at 05:23:17PM -0700, Jakub Kicinski wrote:
> > On Thu, 1 Oct 2020 01:38:17 +0200 Andrew Lunn wrote:
> > > > > > +static void genl_op_from_full(const struct genl_family *family,
> > > > > > + unsigned int i, struct genl_ops *op)
> > > > > > +{
> > > > > > + memcpy(op, &family->ops[i], sizeof(*op));
> > > > >
> > > > > What's wrong with struct assignment? :)
> > > > >
> > > > > *op = family->ops[i];
> > > >
> > > > Code size :)
> > > >
> > > > text data bss dec hex
> > > > 22657 3590 64 26311 66c7 memcpy
> > > > 23103 3590 64 26757 6885 struct
> > >
> > > You might want to show that to the compiler people. Did you look at
> > > the assembly?
> >
> > Somewhere along the line I lost the ability to decipher compiler code :(
>
> Yah, Z80 and 6809 i could sometimes just read the byte codes. That has
> long gone. I tend to read ARM assembly now a days being mostly in the
> embedded world.
>
> So the memcpy version just calls memcpy by the looks of it. I thought
> it might of inlined it, but it has not. Maybe because of the -Os.
>
> The struct assignment is interesting because it appears to be calling
> three functions to do the work. I wonder if it is avoiding copying the
> padding in the structure?
>
> But still, that does not explain an extra 400 bytes in the text
> segment.
FWIW the 400 was without the -Os with -Os it's more like 50. So I'll
just go for it and do the struct assignment.
