PoC feature: drop functions from the runtime #8653
Conversation
|
My only hesitation is that these kinds of quick hacks tend to become permanent (e.g. HL_LLVM_ARGS) because they solve the problem adequately. But I also don't want to let the perfect be the enemy of the good. I think we should probably merge it. Another thought is that renaming the runtime func along the lines of Zalman's suggestion would be more powerful because your version would have the option of deferring to the default version. But that could easily be a future PR done by the first person who needs that. |
…P_FUNCS environment variable, specifying a comma-separated list.
b63f7df to
cf0d1da
Compare
|
I'm again maintaining too many branches of my own that I depend on. Can we land this? I implemented your feedback. I didn't start the buildbots, as nothing in the entire build uses this environment flag (and LLVM is badly broken again either way). Running the build bots is useless on this PR I think. I'd argue to just inspect the code. It works for me: I delete |
|
I've started the bots, just to check it compiles everywhere, even if it's not run. It's also sometimes useful to have a PR where you know all the failures are unrelated to the PR. |
True, although we already have #8691 for that 😋, but fair, it's been a few days since it ran. |
|
We land? |
Proof of Concept: I know that the long-term solution is more elaborate (i.e. runtime function renaming), but this 50 cent hack does the trick for me without any manual steps in my build process.
The
HL_RUNTIME_DROP_FUNCSenvironment variable is checked for a comma-separated list of function names to remove from the runtime. Instead of actually deleting them, their body is removed, and their linkage is changed to extern.@zvookin @abadams Do we want this feature? If so, do we need any changes?
This fixed my issue against which I was battling for 2 days with the Windows linker. Tested this on both Linux and Windows with success.