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
On Jul 26, 2009, at 5:25 AM, Richard Pennington wrote:> 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. :-(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'.
Mike Stump wrote:> On Jul 26, 2009, at 5:25 AM, Richard Pennington wrote: >> 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. :-( > > 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'.I like that idea, too. But unfortunately at (bc) link time, the linker doesn't know the functions are required. Maybe a hook to pull the bitcode for support functions out of a library as needed during code generation? -Rich
On Sun, Jul 26, 2009 at 5:25 AM, Richard Pennington<rich at pennware.com> wrote:> 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. :-( >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. - Devang
Alireza.Moshtaghi at microchip.com
2009-Jul-27 19:05 UTC
[LLVMdev] Whole program compile/link
> 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.