Support LLVM bitcode files in the foreign system for LTO oppertunities with 3rd party code.

[JesseRMeyer]

If the foreign system understands LLVM bitcode files, then any library compiled by LLVM to LLVM bitcode will be ready for LTO opportunities in Odin programs (I don't know what the ABI implications are for non C libraries). Zig already provides native, out of the box LTO for Zig and C code together, but through the foreign system, Odin's reach would extend much further by comparison.

For example: foreign import lib "../lib/stb_image_resize.bc"

This feature would, naturally, be conditional on the LLVM backend.

[github-actions[bot]]

Hello!

I am marking this issue as stale as it has not received any engagement from the community or maintainers 120 days. That does not imply that the issue has no merit! If you feel strongly about this issue

• open a PR referencing and resolving the issue;
• leave a comment on it and discuss ideas how you could contribute towards resolving it;
• leave a comment and describe in detail why this issue is critical for your use case;
• open a new issue with updated details and a plan on resolving the issue.

The motivation for this automation is to help prioritize issues in the backlog and not ignore, reject, or belittle anyone..

[JesseRMeyer]

Implementing this should be fairly straight forward since I expect all that really needs to happen is for the compiler to feed the linker a file '.bc' file.. Just a matter of priorities.

[gingerBill]

Is this actually useful?

[JesseRMeyer]

Maybe, here are two situations to consider:

• .bc would afford Odin essentially LTO=thin for packages built by any language targeting LLVM bitcode. Including itself.
• May interact favorably with -use-separate-modules.