Whole program compile/link

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

Whole program compile/link

Richard Pennington
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
_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: Whole program compile/link

Aaron Gray-3
> 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

_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: Whole program compile/link

Mike Stump
In reply to this post by Richard Pennington
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'.
_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: Whole program compile/link

Richard Pennington
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
_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: Whole program compile/link

Devang Patel-2
In reply to this post by Richard Pennington
On Sun, Jul 26, 2009 at 5:25 AM, Richard Pennington<[hidden email]> 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
_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: Whole program compile/link

Alireza.Moshtaghi

> 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.

_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: Whole program compile/link

Richard Pennington
[hidden email] wrote:
> 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)

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

_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev