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
Hello, Just wondering if anyone had ideas on this and I apologize if bumps are frowned upon. Thanks, Javier On 7/16/2009 2:07 AM, Javier Martinez 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 > >
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 >
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>