Re: [RFC PATCH] tg3: Convert chip type macros to inline functions

Michael Chan
2013-02-07T00:41:18Z

On Wed, 2013-02-06 at 15:44 -0800, Joe Perches wrote:
> There are several macros that are used for
> chip identification.
>
> Perhaps it'd be better to use static inlines
> instead of these macros as the code becomes a
> bit more readable with less uppercase use.
>
> It's neater, shorter, and maybe less error prone.
>
> GET_ASIC_REV(tp->pci_chip_rev_id) -> tg3_asic_rev(tp)
> GET_CHIP_REV(tp->pci_chip_rev_id) -> tg3_chip_rev(tp)
> GET_METAL_REV(tp->pci_chip_rev_id) -> tg3_metal_rev(tp) (unused)
>
> For example:
>
> #define GET_ASIC_REV(CHIP_REV_ID) ((CHIP_REV_ID) >> 12)
>
> becomes:
>
> static inline u32 tg3_asic_rev(const struct tg3 *tp)
> {
> return tp->pci_chip_rev_id >> 12;
> }
>
> (this macro is only used as GET_ASIC_REV(tp->pci_chip_rev_id))
>
> To me the negative to these conversions is at
> least for gcc 4.7.2, the overall code size
> increases
>
> $ size drivers/net/ethernet/broadcom/tg3.o*
> text data bss dec hex filename
> 203426 13446 55744 272616
> 428e8 drivers/net/ethernet/broadcom/tg3.o.new
> 202135 13446 55144 270725
> 42185 drivers/net/ethernet/broadcom/tg3.o.old
>
> I'm not sure why gcc doesn't do the optimization
> and code generation the same way. I expected it
> to and also tried __always_inline with the same
> compiled object size. Looking at the .lst files
> doesn't give much clue _why_ these objects are
> different.

I think these don't have to be inline. there is only one call in the
fast path that I can see (tg3_start_xmit), and we can easily change that
to test for a flag instead. I wonder if that will make it smaller.