Hi,
I have a little conundrum. I want to bitcode link a whole program, but I've run into a roadblock. During code generation on a processor that doesn't support e.g. floating point, a floating point mul is turned into a function call. This isn't known at bitcode linking time so the appropriate bitcode for the mul isn't linked.
Is there a pass I can run that will do the appropriate conversion to the bitcode so that I can get the bitcode mul pulled in?
I suppose that an option would be to put the support stuff in a file that is linked in always and let the optimizer drop functions that aren't referenced. 
-Rich
Hi,
I have a little conundrum. I want to bitcode link a whole program, but
I've run into a roadblock. During code generation on a processor that
doesn't support e.g. floating point, a floating point mul is turned into
a function call. This isn't known at bitcode linking time so the
appropriate bitcode for the mul isn't linked.
Is there a pass I can run that will do the appropriate conversion to the
bitcode so that I can get the bitcode mul pulled in?
I suppose that an option would be to put the support stuff in a file
that is linked in always and let the optimizer drop functions that
aren't referenced.
LLVM bitcode is not target neutral. The olny wey I can think of doing these sorts of things is to miss the lowering stanges when generating .bc files, then on linking them do the lowering. But there are probably other target sppecific issues to deal with too.
Aaron
I like the idea of modeling this as a .a file, and then letting the linker figure out that there are references to the routines and have it pull them in. If your linker doesn't support this directly, you can just bundle them all up and include in the `program'.
We ran into to this. There is not any easy solution here. The
optimizer does not know what not to destroy if the code generator
introduces new uses after optimization phase. One solution is to keep
this support functions in native .a (archive file) and let native
linker complete the final link stage to link in these support
functions.
We ran into to this. There is not any easy solution here. The
optimizer does not know what not to destroy if the code generator
introduces new uses after optimization phase. One solution is to keep
this support functions in native .a (archive file) and let native
linker complete the final link stage to link in these support
functions.
This is exactly what we are doing for PIC16 port;
Would it make sense that front-end (clang) had a way to know if such
operations are native or not; if not, it would generate calls to
appropriate standard intrinsic routine...
These intrinsics can be implemented as .bc (to be linked by llvm-ld,
enabling further lto optimizations because these are standard intrinsics
and optimizers can know about them) or as target native file (to be
linked by native linker)
A.
I really want the intrinsic functions to be part of the LTO, so I guess that having the front-end use the functions explicitly is the way to go. I was hoping I wouldn't have to do that. I'd like to avoid native .a files if possible.
-Rich