| Message ID | 20211127170320.77963-1-colin.i.king@gmail.com (mailing list archive) |
|---|---|
| State | Rejected, archived |
| Headers | show |
| Series | x86/platform/uv: make const pointer dots a static const array | expand |
On Sat, Nov 27, 2021 at 05:03:20PM +0000, Colin Ian King wrote: > Don't populate the const array dots on the stack That is a misunderstanding of what the original code does. The original code has a constant char array (string constant) that is placed in an initialized data section of memory, the address off which would be assigned to the pointer "dots" on the stack -- to be clear, stack contents would not be a full array, but a pointer to it. Then that pointer would be passed to the pr_info function (which boils down to a call to printk). Examination of the disassembly shows that the compiler actually eliminates the creation of the pointer "dots" on the stack and just passes the address of the string constant to the printk function. So this change should not have any actual effect (I don't know where you got the "shrinks object code" from), and in my humble opinion makes the code less clear. As such, unless there's something here I don't understand, I vote to reject this patch. --> Steve Wahl <steve.wahl@hpe.com> > but make it static > const and make the pointer an array to remove a dereference. Shrinks > object code a few bytes too. > > Signed-off-by: Colin Ian King <colin.i.king@gmail.com> > --- > arch/x86/platform/uv/uv_nmi.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/arch/x86/platform/uv/uv_nmi.c b/arch/x86/platform/uv/uv_nmi.c > index 1e9ff28bc2e0..2c69a0c30632 100644 > --- a/arch/x86/platform/uv/uv_nmi.c > +++ b/arch/x86/platform/uv/uv_nmi.c > @@ -725,7 +725,7 @@ static void uv_nmi_dump_cpu_ip(int cpu, struct pt_regs *regs) > */ > static void uv_nmi_dump_state_cpu(int cpu, struct pt_regs *regs) > { > - const char *dots = " ................................. "; > + static const char dots[] = " ................................. "; > > if (cpu == 0) > uv_nmi_dump_cpu_ip_hdr(); > -- > 2.33.1 >
On Tue, 2021-11-30 at 13:34 -0600, Steve Wahl wrote: > On Sat, Nov 27, 2021 at 05:03:20PM +0000, Colin Ian King wrote: > > Don't populate the const array dots on the stack [] > Examination of the disassembly shows that the compiler actually > eliminates the creation of the pointer "dots" on the stack and just > passes the address of the string constant to the printk function. > > So this change should not have any actual effect (I don't know where > you got the "shrinks object code" from), and in my humble opinion > makes the code less clear. Probably shrinks an allmodconfig where the symbols are referenced. It probably doesn't do anything to a defconfig. > As such, unless there's something here I don't understand, I vote to > reject this patch. [] > > but make it static > > const and make the pointer an array to remove a dereference. Shrinks > > object code a few bytes too. [] > > diff --git a/arch/x86/platform/uv/uv_nmi.c b/arch/x86/platform/uv/uv_nmi.c [] > > @@ -725,7 +725,7 @@ static void uv_nmi_dump_cpu_ip(int cpu, struct pt_regs *regs) > > */ > > static void uv_nmi_dump_state_cpu(int cpu, struct pt_regs *regs) > > { > > - const char *dots = " ................................. "; > > + static const char dots[] = " ................................. ";
On Tue, Nov 30, 2021 at 04:26:39PM -0800, Joe Perches wrote: > On Tue, 2021-11-30 at 13:34 -0600, Steve Wahl wrote: > > On Sat, Nov 27, 2021 at 05:03:20PM +0000, Colin Ian King wrote: > > > Don't populate the const array dots on the stack > [] > > Examination of the disassembly shows that the compiler actually > > eliminates the creation of the pointer "dots" on the stack and just > > passes the address of the string constant to the printk function. > > > > So this change should not have any actual effect (I don't know where > > you got the "shrinks object code" from), and in my humble opinion > > makes the code less clear. > > Probably shrinks an allmodconfig where the symbols are referenced. > It probably doesn't do anything to a defconfig. OK, I looked. Under allmodconfig, the new code is one byte smaller. Defconfig doesn't include CONFIG_X86_UV and this file doesn't get compiled. Using defconfig plus CONFIG_X86_UV and prerequisites, the new code is 24 bytes larger, probably because of alignment added. allmodconfig: text data bss dec hex filename 30827 18358 1472 50657 c5e1 uv_nmi.o 30828 18358 1472 50658 c5e2 uv_nmi.orig.o default config + CONFIG_X86_UV: text data bss dec hex filename 9918 216 160 10294 2836 uv_nmi.o 9894 216 160 10270 281e uv_nmi.orig.o So I still don't think this patch makes sense. --> Steve Wahl > > As such, unless there's something here I don't understand, I vote to > > reject this patch. > [] > > > but make it static > > > const and make the pointer an array to remove a dereference. Shrinks > > > object code a few bytes too. > [] > > > diff --git a/arch/x86/platform/uv/uv_nmi.c b/arch/x86/platform/uv/uv_nmi.c > [] > > > @@ -725,7 +725,7 @@ static void uv_nmi_dump_cpu_ip(int cpu, struct pt_regs *regs) > > > */ > > > static void uv_nmi_dump_state_cpu(int cpu, struct pt_regs *regs) > > > { > > > - const char *dots = " ................................. "; > > > + static const char dots[] = " ................................. "; > >
Hi, On 12/1/21 22:39, Steve Wahl wrote: > On Tue, Nov 30, 2021 at 04:26:39PM -0800, Joe Perches wrote: >> On Tue, 2021-11-30 at 13:34 -0600, Steve Wahl wrote: >>> On Sat, Nov 27, 2021 at 05:03:20PM +0000, Colin Ian King wrote: >>>> Don't populate the const array dots on the stack >> [] >>> Examination of the disassembly shows that the compiler actually >>> eliminates the creation of the pointer "dots" on the stack and just >>> passes the address of the string constant to the printk function. >>> >>> So this change should not have any actual effect (I don't know where >>> you got the "shrinks object code" from), and in my humble opinion >>> makes the code less clear. >> >> Probably shrinks an allmodconfig where the symbols are referenced. >> It probably doesn't do anything to a defconfig. > > OK, I looked. Under allmodconfig, the new code is one byte smaller. > > Defconfig doesn't include CONFIG_X86_UV and this file doesn't get > compiled. > > Using defconfig plus CONFIG_X86_UV and prerequisites, the new code is > 24 bytes larger, probably because of alignment added. > > allmodconfig: > > text data bss dec hex filename > 30827 18358 1472 50657 c5e1 uv_nmi.o > 30828 18358 1472 50658 c5e2 uv_nmi.orig.o > > default config + CONFIG_X86_UV: > > text data bss dec hex filename > 9918 216 160 10294 2836 uv_nmi.o > 9894 216 160 10270 281e uv_nmi.orig.o > > So I still don't think this patch makes sense. I agree, so I've dropped this patch from the queue. Regards, Hans
On 02/12/2021 09:10, Hans de Goede wrote: > Hi, > > On 12/1/21 22:39, Steve Wahl wrote: >> On Tue, Nov 30, 2021 at 04:26:39PM -0800, Joe Perches wrote: >>> On Tue, 2021-11-30 at 13:34 -0600, Steve Wahl wrote: >>>> On Sat, Nov 27, 2021 at 05:03:20PM +0000, Colin Ian King wrote: >>>>> Don't populate the const array dots on the stack >>> [] >>>> Examination of the disassembly shows that the compiler actually >>>> eliminates the creation of the pointer "dots" on the stack and just >>>> passes the address of the string constant to the printk function. >>>> >>>> So this change should not have any actual effect (I don't know where >>>> you got the "shrinks object code" from), and in my humble opinion >>>> makes the code less clear. >>> >>> Probably shrinks an allmodconfig where the symbols are referenced. >>> It probably doesn't do anything to a defconfig. >> >> OK, I looked. Under allmodconfig, the new code is one byte smaller. >> >> Defconfig doesn't include CONFIG_X86_UV and this file doesn't get >> compiled. >> >> Using defconfig plus CONFIG_X86_UV and prerequisites, the new code is >> 24 bytes larger, probably because of alignment added. >> >> allmodconfig: >> >> text data bss dec hex filename >> 30827 18358 1472 50657 c5e1 uv_nmi.o >> 30828 18358 1472 50658 c5e2 uv_nmi.orig.o >> >> default config + CONFIG_X86_UV: >> >> text data bss dec hex filename >> 9918 216 160 10294 2836 uv_nmi.o >> 9894 216 160 10270 281e uv_nmi.orig.o >> >> So I still don't think this patch makes sense. > > I agree, so I've dropped this patch from the queue. > > Regards, > > Hans > +1. Apologies for wasting your valuable time. I appreciate the detailed review. Colin
diff --git a/arch/x86/platform/uv/uv_nmi.c b/arch/x86/platform/uv/uv_nmi.c index 1e9ff28bc2e0..2c69a0c30632 100644 --- a/arch/x86/platform/uv/uv_nmi.c +++ b/arch/x86/platform/uv/uv_nmi.c @@ -725,7 +725,7 @@ static void uv_nmi_dump_cpu_ip(int cpu, struct pt_regs *regs) */ static void uv_nmi_dump_state_cpu(int cpu, struct pt_regs *regs) { - const char *dots = " ................................. "; + static const char dots[] = " ................................. "; if (cpu == 0) uv_nmi_dump_cpu_ip_hdr();
Don't populate the const array dots on the stack but make it static const and make the pointer an array to remove a dereference. Shrinks object code a few bytes too. Signed-off-by: Colin Ian King <colin.i.king@gmail.com> --- arch/x86/platform/uv/uv_nmi.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)