From: "Toke Høiland-Jørgensen" <toke@toke.dk>
To: Rosen Penev <rosenp@gmail.com>, linux-wireless@vger.kernel.org
Cc: Nathan Chancellor <nathan@kernel.org>,
Nick Desaulniers <nick.desaulniers+lkml@gmail.com>,
Bill Wendling <morbo@google.com>,
Justin Stitt <justinstitt@google.com>,
open list <linux-kernel@vger.kernel.org>,
"open list:CLANG/LLVM BUILD SUPPORT:Keyword:b(?i:clang|llvm)b"
<llvm@lists.linux.dev>
Subject: Re: [PATCH ath-next] ath9k: eeprom: alias vpdTableI onto vpdTableL to shrink stack frame
Date: Thu, 18 Jun 2026 11:51:38 +0200 [thread overview]
Message-ID: <87pl1ofa6t.fsf@toke.dk> (raw)
In-Reply-To: <20260617234105.284358-1-rosenp@gmail.com>
Rosen Penev <rosenp@gmail.com> writes:
> vpdTableL, vpdTableR, and vpdTableI are never live simultaneously.
> vpdTableL and vpdTableR are consumed during the frequency-interpolation
> step that writes vpdTableI; after the if/else they are never read
> again. Reuse vpdTableL for the interpolated result (what was
> vpdTableI), reducing the stack frame by one 256-byte array.
>
> The read-via-write in the else branch is safe: ath9k_hw_interpolate()
> receives vpdTableL[i][j] by value as a function argument before the
> return value is written back to vpdTableL[i][j].
>
> Stack frame size change (x86_64, clang):
> before: 0x440 (1088 B)
> after: 0x330 (816 B)
Huh? These are static variables, how is this affecting stack usage?
I assume this is against your previous (broken) patch?
Anyway, adding this kind of aliasing to fix a problem that you
introduced by changing working code with no real benefit is not an
improvement. I'm OK with fixing actual bugs, but this is just mindless
churn...
-Toke
prev parent reply other threads:[~2026-06-18 9:51 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-06-17 23:41 [PATCH ath-next] ath9k: eeprom: alias vpdTableI onto vpdTableL to shrink stack frame Rosen Penev
2026-06-18 9:51 ` Toke Høiland-Jørgensen [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87pl1ofa6t.fsf@toke.dk \
--to=toke@toke.dk \
--cc=justinstitt@google.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-wireless@vger.kernel.org \
--cc=llvm@lists.linux.dev \
--cc=morbo@google.com \
--cc=nathan@kernel.org \
--cc=nick.desaulniers+lkml@gmail.com \
--cc=rosenp@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.