The symbol 'HUF_compressWeights_wksp' is not used outside of
huf_compress.c, so this commit marks it static.
Signed-off-by: Zhao Xuehui <[email protected]>
---
lib/zstd/huf_compress.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/lib/zstd/huf_compress.c b/lib/zstd/huf_compress.c
index fd32838c185f..1e5e001c3d41 100644
--- a/lib/zstd/huf_compress.c
+++ b/lib/zstd/huf_compress.c
@@ -79,7 +79,8 @@ unsigned HUF_optimalTableLog(unsigned maxTableLog, size_t srcSize, unsigned maxS
* Note : all elements within weightTable are supposed to be <= HUF_TABLELOG_MAX.
*/
#define MAX_FSE_TABLELOG_FOR_HUFF_HEADER 6
-size_t HUF_compressWeights_wksp(void *dst, size_t dstSize, const void *weightTable, size_t wtSize, void *workspace, size_t workspaceSize)
+static size_t HUF_compressWeights_wksp(void *dst, size_t dstSize, const void *weightTable,
+ size_t wtSize, void *workspace, size_t workspaceSize)
{
BYTE *const ostart = (BYTE *)dst;
BYTE *op = ostart;
On Thu, Apr 8, 2021 at 5:55 AM Zhao Xuehui <[email protected]> wrote:
>
> The symbol 'HUF_compressWeights_wksp' is not used outside of
> huf_compress.c, so this commit marks it static.
Reviewed-by: Nick Desaulniers <[email protected]>
Quite a few other functions are declared in a header, but I don't see
any existing callers in tree. I wonder if the maintainer could
consider cleaning these up so that we don't retain them in binaries
without dead code elimination enabled, or if there's a need to keep
this code in line with an external upstream codebase?
>
> Signed-off-by: Zhao Xuehui <[email protected]>
> ---
> lib/zstd/huf_compress.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/lib/zstd/huf_compress.c b/lib/zstd/huf_compress.c
> index fd32838c185f..1e5e001c3d41 100644
> --- a/lib/zstd/huf_compress.c
> +++ b/lib/zstd/huf_compress.c
> @@ -79,7 +79,8 @@ unsigned HUF_optimalTableLog(unsigned maxTableLog, size_t srcSize, unsigned maxS
> * Note : all elements within weightTable are supposed to be <= HUF_TABLELOG_MAX.
> */
> #define MAX_FSE_TABLELOG_FOR_HUFF_HEADER 6
> -size_t HUF_compressWeights_wksp(void *dst, size_t dstSize, const void *weightTable, size_t wtSize, void *workspace, size_t workspaceSize)
> +static size_t HUF_compressWeights_wksp(void *dst, size_t dstSize, const void *weightTable,
> + size_t wtSize, void *workspace, size_t workspaceSize)
> {
> BYTE *const ostart = (BYTE *)dst;
> BYTE *op = ostart;
>
--
Thanks,
~Nick Desaulniers
On Fri, Apr 9, 2021 at 2:20 AM Nick Desaulniers <[email protected]> wrote:
>
> Quite a few other functions are declared in a header, but I don't see
> any existing callers in tree. I wonder if the maintainer could
> consider cleaning these up so that we don't retain them in binaries
> without dead code elimination enabled, or if there's a need to keep
> this code in line with an external upstream codebase?
Yeah, the equivalent cleanup was done upstream by Nick in 2018 [1],
but there has been no major update to lib/zstd since 2017.
Thus a cleanup would actually make it closer to upstream, which is the
best case scenario :)
Reviewed-by: Miguel Ojeda <[email protected]>
[1] https://github.com/facebook/zstd/commit/f2d6db45cd28457fa08467416e8535985f062859
Cheers,
Miguel
> On Apr 8, 2021, at 8:09 PM, Miguel Ojeda <[email protected]> wrote:
>
> On Fri, Apr 9, 2021 at 2:20 AM Nick Desaulniers <[email protected]> wrote:
>>
>> Quite a few other functions are declared in a header, but I don't see
>> any existing callers in tree. I wonder if the maintainer could
>> consider cleaning these up so that we don't retain them in binaries
>> without dead code elimination enabled, or if there's a need to keep
>> this code in line with an external upstream codebase?
>
> Yeah, the equivalent cleanup was done upstream by Nick in 2018 [1],
> but there has been no major update to lib/zstd since 2017.
>
> Thus a cleanup would actually make it closer to upstream, which is the
> best case scenario :)
>
> Reviewed-by: Miguel Ojeda <[email protected]>
>
> [1] https://github.com/facebook/zstd/commit/f2d6db45cd28457fa08467416e8535985f062859
This looks good to me as well. I have a patchset up to use upstream zstd directly in the kernel [0].
That will allow us to keep zstd up to date. And after that lands, I hope to set up a zstd linux tree
to make merging patches into lib/zstd easier, since over the years quite a few have been ignored.
[0] https://www.mail-archive.com/[email protected]/msg2532407.html
Best,
Nick Terrell
> Cheers,
> Miguel