ExpandLibCall function does not try to resolve libcalls to currently lowered module.

[llvmbot]

Bugzilla Link	2673
Resolution	WONTFIX
Resolved on	Oct 16, 2008 01:37
Version	unspecified
OS	Linux
Reporter	LLVM Bugzilla Contributor
CC	@asl,@pjaaskel

Extended Description

When operation which is not supported by target are generated by ISEL lowering (such as div and rem) and there is no native linker available for target, the emulation code for libcall functions needs to be linked to program statically.

However even if libcall functions are found from currently lowered module, ExpandLibCall function does not try to use those functions for emulating e.g. div functionality. It just automatically supposes that libcall is external and will be linked to code later on.

Maybe ExpandLibCall function should first check if needed libcall is already found from module and use that implementation and if it's not found then rely on externally linked libcall code?

In my case I link in libcall code just before ISEL and after ISEL there is still external references to __divsi3 symbol in those places where div was expanded, even though the function by that name is found from the same program.

[lattner]

We don't want the llvm backend to implicitly serve as a linker, sorry.