Hi Daniel, Thanks for the reply. If I understand correctly, your suggestion is to have the backend call a library that handles the built-in functions. Would the calls need to be lowered and redirected (e.g. by a big switch statement or a jump table) to the corresponding function in the library? Thanks, Javier On 7/20/2009 12:11 AM, Daniel Dunbar wrote:> Hi Javier, > > I'm not the right person to answer your question, but since no one > else took it: I believe this is a situation where the backend would > typically emit a call the the compiler's runtime library (e.g., > libgcc). > > While it isn't currently completely wired up, we do have our own > compiler runtime library available under the compiler-rt project in > the LLVM repo. > > - Daniel > > On Thu, Jul 16, 2009 at 2:07 AM, Javier Martinez<javier at jmartinez.org> wrote: > >> Hi, >> >> I'm trying to add support in my back end for certain functions that are >> seen as built-in by the target. Some of these functions can be >> implemented in a) LLVM, and some in b) the native target language. >> >> My approach to case a) is to write the built-in function implementation >> in C, compile it to LLVM using Clang, link it to the module that uses it >> and finally add a pass to inline it. The last two steps can be made >> inside a ModulePass. The definition of TargetMachine allows for any pass >> manager deriving form BasicPass to be passed to AddPassesToEmitFile. >> However, I see that llc uses a FunctionPassManager for all the passes. A >> (module)PassManager is used only if the target implements >> AddPassesToEmitWholeFile but the comments on the base class discourage >> this path. Am I approaching the problem the wrong way? >> >> I haven't worked much on case b) but my idea was to use a similar >> approach but instead of writing the built-in function implementation in >> straight C an asm block would be used to insert the code. Does this make >> sense? >> >> Thanks, >> Javier >> >> >> _______________________________________________ >> LLVM Developers mailing list >> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >> >> > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20090720/3585e0db/attachment.html>
I don't see why. Your compiler would just do a declare and then a call, and your runtime function gets called. On Mon, Jul 20, 2009 at 4:13 AM, Javier Martinez<javier at jmartinez.org> wrote:> Hi Daniel, > > Thanks for the reply. If I understand correctly, your suggestion is to have > the backend call a library that handles the built-in functions. Would the > calls need to be lowered and redirected (e.g. by a big switch statement or a > jump table) to the corresponding function in the library? > > Thanks, > Javier > > On 7/20/2009 12:11 AM, Daniel Dunbar wrote: > > Hi Javier, > > I'm not the right person to answer your question, but since no one > else took it: I believe this is a situation where the backend would > typically emit a call the the compiler's runtime library (e.g., > libgcc). > > While it isn't currently completely wired up, we do have our own > compiler runtime library available under the compiler-rt project in > the LLVM repo. > > - Daniel > > On Thu, Jul 16, 2009 at 2:07 AM, Javier Martinez<javier at jmartinez.org> > wrote: > > > Hi, > > I'm trying to add support in my back end for certain functions that are > seen as built-in by the target. Some of these functions can be > implemented in a) LLVM, and some in b) the native target language. > > My approach to case a) is to write the built-in function implementation > in C, compile it to LLVM using Clang, link it to the module that uses it > and finally add a pass to inline it. The last two steps can be made > inside a ModulePass. The definition of TargetMachine allows for any pass > manager deriving form BasicPass to be passed to AddPassesToEmitFile. > However, I see that llc uses a FunctionPassManager for all the passes. A > (module)PassManager is used only if the target implements > AddPassesToEmitWholeFile but the comments on the base class discourage > this path. Am I approaching the problem the wrong way? > > I haven't worked much on case b) but my idea was to use a similar > approach but instead of writing the built-in function implementation in > straight C an asm block would be used to insert the code. Does this make > sense? > > Thanks, > Javier > > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > > > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > >
The issue is that there is no runtime function. I'm not sure we're in the same page but just in case we aren't I'm trying to provide support for built-in functions at compilation time. Some functions can be expressed in LLVM and others only in the target language. For the first group I'm trying to inline the implementation in a module pass added in addPassesToEmitFile. For the second I'm thinking of using an asm node to insert the implementation. My first question was if the approach is correct; the second was how to add the module pass if addPassesToEmitFile gets a FunctionPAssManager from otp. Thanks, Javier On Mon, 20 Jul 2009 08:33:44 -0500, Kenneth Uildriks <kennethuil at gmail.com> wrote:> I don't see why. Your compiler would just do a declare and then a > call, and your runtime function gets called. > > On Mon, Jul 20, 2009 at 4:13 AM, Javier Martinez<javier at jmartinez.org> > wrote: >> Hi Daniel, >> >> Thanks for the reply. If I understand correctly, your suggestion is to >> have >> the backend call a library that handles the built-in functions. Wouldthe>> calls need to be lowered and redirected (e.g. by a big switch statement >> or a >> jump table) to the corresponding function in the library? >> >> Thanks, >> Javier >> >> On 7/20/2009 12:11 AM, Daniel Dunbar wrote: >> >> Hi Javier, >> >> I'm not the right person to answer your question, but since no one >> else took it: I believe this is a situation where the backend would >> typically emit a call the the compiler's runtime library (e.g., >> libgcc). >> >> While it isn't currently completely wired up, we do have our own >> compiler runtime library available under the compiler-rt project in >> the LLVM repo. >> >> - Daniel >> >> On Thu, Jul 16, 2009 at 2:07 AM, Javier Martinez<javier at jmartinez.org> >> wrote: >> >> >> Hi, >> >> I'm trying to add support in my back end for certain functions that are >> seen as built-in by the target. Some of these functions can be >> implemented in a) LLVM, and some in b) the native target language. >> >> My approach to case a) is to write the built-in function implementation >> in C, compile it to LLVM using Clang, link it to the module that uses it >> and finally add a pass to inline it. The last two steps can be made >> inside a ModulePass. The definition of TargetMachine allows for any pass >> manager deriving form BasicPass to be passed to AddPassesToEmitFile. >> However, I see that llc uses a FunctionPassManager for all the passes. A >> (module)PassManager is used only if the target implements >> AddPassesToEmitWholeFile but the comments on the base class discourage >> this path. Am I approaching the problem the wrong way? >> >> I haven't worked much on case b) but my idea was to use a similar >> approach but instead of writing the built-in function implementation in >> straight C an asm block would be used to insert the code. Does this make >> sense? >> >> Thanks, >> Javier >> >> >> _______________________________________________ >> LLVM Developers mailing list >> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >> >> >> >> _______________________________________________ >> LLVM Developers mailing list >> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >> >> >> _______________________________________________ >> LLVM Developers mailing list >> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >> >> > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev