error: inlining failed in call to 'always_inline' 'XXH3_scrambleAcc_sse2' and 'XXH3_accumulate_sse2' #943
Labels
No labels
announcement
bug
build
CI
dependencies
documentation
duplicate
enhancement
experience feedback
feature request
github_actions
help wanted
install
invalid
Long-term
optimization
portability
question
target-specific
test issue
wontfix
No milestone
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set
Reference
gh-Cyan4973/xxHash#943
Loading…
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
When building
e9455b2c20with GCC 14.1 under MSYS2/MinGW64 using-Og -msse -msse2, I get the following errors.$ gcc --version
gcc.exe (Rev3, Built by MSYS2 project) 14.1.0
Copyright (C) 2024 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
I worked around this by defining
XXH_NO_INLINE_HINTSin debug builds.This issue seems specific to the
-Ogcompilation flag.It also looks strikingly similar to #800.
This issue was supposed to be fixed by #804 (@easyaspi314),
but unfortunately, I can also reproduce it on
MinGW64, currently employinggccv14.2.The surprising part if that a
-Ogtest is part oftest-allnow (@t-mat),and it is rigorously run at every commit on Github Actions.
Checking on my local Ubuntu test system,
-Ogseems to work fine with the exact command line provided above.But note that, by default, Ubuntu 24.04 uses
gcc-13.gcc-11,gcc-12andgcc-13all work fine, but forcing usage ofgcc-14, the same issue asMinGW64becomes visible.Unfortunately, Github Actions cannot run
gcc-14in the linux test, because the latestosversion available there is22.04,and
gcc-14is not available on this version.There is also a
MinGW64test run on Github Actions, but it's simpler, and doesn't include the-Ogtest.Just added a
-Ogtest on ourMinGWCI tests in #983,and they fail, as expected.
Now onto the more difficult exercise of understanding why the compilation failure happens and how to fix that....
edit : as mentioned above by @axelf4 , and also previously on https://github.com/Cyan4973/xxHash/issues/800#issuecomment-1435801892, defining
XXH_NO_INLINE_HINTSas a preprocessor build macro is a valid solution for-Ogto compile properly.Now the question is, is it the proper way to get
-Ogto compile, or should the source code be modified (and how) ?I think it's a question of practicity. Defining
XXH_NO_INLINE_HINTSis a manual operation, and most users will miss it and not know about it, even if documented (though "most users" won't compile with-Ogeither). So, to avoid the back and forth on Github Issues, it would be better if the source code takes care of it automatically.But is that possible ? It's unclear. A big issue is that
-Ogdoesn't signal itself at compilation time, so the code cannot adjust to this compilation flag (otherwise, it would have been easy to just enableXXH_NO_INLINE_HINTSon detection of-Og). Prior fix attempts show that interactions are complex with other compilation mode. It would be a pity to negatively impact general performance just to get-Ogto compile fine ongcc-14.It's interesting to note that, while
-Og -msse2fails inlining,the equivalent
-Og -mavx2doesn't.I looked at the code, in case there would be some difference explaining this outcome, but there isn't any.
The current speculation is that a certain amount of loop unrolling is happening within these functions.
Because
avx2can essentially ingest 2x more data per round, it has 2x less loops.This results in less code, possibly remaining under a certain inlining threshold, defined by
-Og,thus completing inlining successfully for
avx2.This assumption implies that the situation for
-mavx512fshould be even better,but not completely, because
-Og -mavx512ffailed inlining,though in a different function
XXH3_initCustomSecret_avx512()and for a different reason.Note that defining the build macro
XXH_NO_INLINE_HINTSat compilation time works fine foravx512too.The
-Ogcompilation issue proves to be intractable on some compiler versions,and the only thing I can suggest at this point is to recommend using
XXH_NO_INLINE_HINTSwhen compiling with-Ogand document it.Thanks. We did something similar:
github.com/nukeykt/NBlood@4f58b06b5f