| Message ID | 1396215079-7541-1-git-send-email-dvlasenk@redhat.com (mailing list archive) |
|---|---|
| State | Not Applicable, archived |
| Headers | show |
On 30/03/14 23:31, Denys Vlasenko wrote: > Automated script discovered that without forced inlining, > gcc-4.7 generates smaller code for this function. > > There is no need to declare static functions inline anyway: > nowadays gcc detects single-callsite static functions > which benefit from inlining. These patches look awfully familiar. I tend to object, but I don't know the details of this automated script. Does it only look for code size. How about execution time or is this only compile tested? The other thing is that you seem to rely on a specific gcc version. What about pre-4.7? How about different architectures. Was this determined on x86, arm, sparc, mips. All these questions make me say 'nay'. Regards, Arend > Signed-off-by: Denys Vlasenko <dvlasenk@redhat.com> > --- > drivers/net/wireless/brcm80211/brcmfmac/chip.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/net/wireless/brcm80211/brcmfmac/chip.c b/drivers/net/wireless/brcm80211/brcmfmac/chip.c > index df130ef..d020b0b 100644 > --- a/drivers/net/wireless/brcm80211/brcmfmac/chip.c > +++ b/drivers/net/wireless/brcm80211/brcmfmac/chip.c > @@ -933,7 +933,7 @@ static bool brcmf_chip_cm3_exitdl(struct brcmf_chip_priv *chip) > return true; > } > > -static inline void > +static void > brcmf_chip_cr4_enterdl(struct brcmf_chip_priv *chip) > { > struct brcmf_core *core; > -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 03/31/2014 09:38 AM, Arend van Spriel wrote: > On 30/03/14 23:31, Denys Vlasenko wrote: >> Automated script discovered that without forced inlining, >> gcc-4.7 generates smaller code for this function. >> >> There is no need to declare static functions inline anyway: >> nowadays gcc detects single-callsite static functions >> which benefit from inlining. > > These patches look awfully familiar. I tend to object, but I don't know the details of this automated script. The script removes "static" keyword, recompiles the .c file, compares the sizes, and if code size went down, creates a patch > How about execution time or is this only compile tested? The change adds one pair of call/return instructions - probably around 5-10 CPU cycles. The function in question is a part of firmware download logic, which is nowhere near being hot path/. > The other thing is that you seem to rely on a specific gcc version. > What about pre-4.7? How about different architectures. > Was this determined on x86, arm, sparc, mips. > All these questions make me say 'nay'. Not making functions inline unless there is a good reason is a general good coding practice. It is not a compiler- or architecture-specific optimization. -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 03/31/2014 01:18 PM, Denys Vlasenko wrote: > The script removes "static" keyword, recompiles the .c file, > compares the sizes, and if code size went down, > creates a patch Erm... I meant, "removes 'inline' keyword". "static", or course, is not removed. -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 31/03/14 13:18, Denys Vlasenko wrote: > On 03/31/2014 09:38 AM, Arend van Spriel wrote: >> On 30/03/14 23:31, Denys Vlasenko wrote: >>> Automated script discovered that without forced inlining, >>> gcc-4.7 generates smaller code for this function. >>> >>> There is no need to declare static functions inline anyway: >>> nowadays gcc detects single-callsite static functions >>> which benefit from inlining. >> >> These patches look awfully familiar. I tend to object, but I don't know the details of this automated script. > > The script removes "static" keyword, recompiles the .c file, > compares the sizes, and if code size went down, > creates a patch > >> How about execution time or is this only compile tested? > > The change adds one pair of call/return instructions - > probably around 5-10 CPU cycles. > > The function in question is a part of firmware download logic, > which is nowhere near being hot path/. True. My remarks are on all four patches and I just replied to the first patch. The other patches are in interrupt handling code, ie. interrupt or bottom-halve context. >> The other thing is that you seem to rely on a specific gcc version. >> What about pre-4.7? How about different architectures. >> Was this determined on x86, arm, sparc, mips. >> All these questions make me say 'nay'. > > Not making functions inline unless there is a good reason > is a general good coding practice. It is not a compiler- > or architecture-specific optimization. Agree, but you seem to assume that in this case there is no good reason. Regards, Arend -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/drivers/net/wireless/brcm80211/brcmfmac/chip.c b/drivers/net/wireless/brcm80211/brcmfmac/chip.c index df130ef..d020b0b 100644 --- a/drivers/net/wireless/brcm80211/brcmfmac/chip.c +++ b/drivers/net/wireless/brcm80211/brcmfmac/chip.c @@ -933,7 +933,7 @@ static bool brcmf_chip_cm3_exitdl(struct brcmf_chip_priv *chip) return true; } -static inline void +static void brcmf_chip_cr4_enterdl(struct brcmf_chip_priv *chip) { struct brcmf_core *core;
Automated script discovered that without forced inlining, gcc-4.7 generates smaller code for this function. There is no need to declare static functions inline anyway: nowadays gcc detects single-callsite static functions which benefit from inlining. Signed-off-by: Denys Vlasenko <dvlasenk@redhat.com> --- drivers/net/wireless/brcm80211/brcmfmac/chip.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)