Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Add a target option "merge-functions", and a corresponding -Z flag (works around #57356) #57268
This commit adds a target option "merge-functions", which takes values in ("disabled", "trampolines", or "aliases" (default is "aliases")), to allow targets to opt out of the MergeFunctions LLVM pass. Additionally, the latest commit also adds an optional -Z flag, "merge-functions", which takes the same values and has precedence over the target option when both are specified.
This works around #57356.
Basically, the problem is that the MergeFunctions pass, which rustc currently enables by default at -O2 and -O3 , and
The current behavior of rustc is to enable MergeFunctions at -O2 and -O3 , and also to enable the use of function aliases within MergeFunctions  . MergeFunctions seems to have some benefits, such as reducing code size and fixing a crash , which is why it is enabled. However, MergeFunctions both with and without function aliases is incompatible with the NVPTX target; a more detailed example for both cases is given below.
clang's "solution" is to have a "-fmerge-functions" flag that opts in to the MergeFunctions pass, but it is not enabled by default.
Consider an example Rust lib using
This error happens because: (1) functions
Okay, so we can try omitting "mergefunc-use-aliases", and then rustc will happily emit PTX assembly: https://github.com/peterhj/nvptx-mergefunc-bug/blob/master/nocore-mergefunc-nousealiases-bad.ptx. However, this PTX is invalid! When we try to assemble it with
What's happening is that MergeFunctions rewrites the
If we disable the MergeFunctions pass from running at all, rustc generates correct PTX assembly: https://github.com/peterhj/nvptx-mergefunc-bug/blob/master/nocore-nomergefunc-ok.ptx
Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @zackmdavis (or someone else) soon.
If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes.
Please see the contribution instructions for more information.
It would also be nice to gain a
Does the NVPTX target, perchance, support the non-
Yes, this is definitely an LLVM bug and it would be good to fix it there in the long term.
Would it be possible to do something similar to how weak functions are handled? I.e., when merging functions with the
The latest commit will add a