search for: hwu

Hi, On Fri, Jun 4, 2010 at 5:18 AM, Pekka Nikander <pekka.nikander at nomadiclab.com> wrote: >  Would the best way be to add an option to -loop-unroll, and hack away at lib/Transforms/Utils/LoopUnroll.cpp? Instead, the better alternative is to write another pass similar to LoopUnrollPass.cpp (say LoopPeelPass.cpp) and add new option -loop-peel. The new pass could use llvm::UnrollLoop()

On Fri, Apr 27, 2012 at 7:40 PM, Yabin Hu <yabin.hwu at gmail.com> wrote: > Hi LLVMers, > > The attached patch adds a new Intrinsic named "llvm.codegen" to support > embedded LLVM IR code generation. **The 'llvm.codegen' intrinsic uses > the LLVM back ends to generate code for embedded LLVM IR strings. The code &...

Hi Justin, Thanks very much for your comments. 2012/4/28 Justin Holewinski <justin.holewinski at gmail.com> > On Fri, Apr 27, 2012 at 7:40 PM, Yabin Hu <yabin.hwu at gmail.com> wrote: > >> The attached patch adds a new Intrinsic named "llvm.codegen" to support >> embedded LLVM IR code generation. **The 'llvm.codegen' intrinsic uses >> the LLVM back ends to generate code for embedded LLVM IR strings. The code >&gt...

Hi LLVMers, The attached patch adds a new Intrinsic named "llvm.codegen" to support embedded LLVM IR code generation. **The 'llvm.codegen' intrinsic uses the LLVM back ends to generate code for embedded LLVM IR strings. The code generation target can be same or different to the one of the parent module. The original motivation inspiring us to add this intrinsic, is to

On 04/28/2012 10:25 AM, Yabin Hu wrote: > Hi Justin, > > Thanks very much for your comments. > > 2012/4/28 Justin Holewinski <justin.holewinski at gmail.com > <mailto:justin.holewinski at gmail.com>> > > On Fri, Apr 27, 2012 at 7:40 PM, Yabin Hu <yabin.hwu at gmail.com > <mailto:yabin.hwu at gmail.com>> wrote: > > The attached patch adds a new Intrinsic named "llvm.codegen" to > support embedded LLVM IR code generation. The 'llvm.codegen' > intrinsic uses the LLVM back ends to gene...

Hi all, Does PTX backend support llvm sitofp instruction? I failed to compile my llvm source when use llc -march=ptx32. The reason is that the source has a sitofp instruction. After i changed the instruction into uitofp manually, it passed. Thanks in advance, best, Yabin -------------- next part -------------- An HTML attachment was scrubbed... URL:

Hi Justin, In the PTX backend, "ret" instruction at the end of a ptx_kernel function is translated to "exit" instruction. A test case named exit.ll demos this. But in the NVPTX backend, it seems that you didn't do such a translation. Why do you choose this? Is this due to the changes of the NVIDA PTX itself? Thanks, Yabin -------------- next part -------------- An HTML

I am working on heavily optimising unusually static C++ code, and have encountered a situation where I basically want an optimiser that would speculatively unroll a loop to see if the first round of the loop could be optimised further. (I happen to know that it is possible.) The previous optimisations that produce the loop in the first place already do a magical job (relying heavily on constant

...each of the source file into a .bc file. If there's any automated way to infer about all the subroutines that one function needs, clang them into .bc file and link them into a stand-alone .bc library, that will be more than appreciated:-) On Mon, Sep 15, 2014 at 11:30 AM, Yabin Hu <yabin.hwu at gmail.com> wrote: > Hi Liwei, > > You may at first look into whether there is a llvm intrinsic for the > function you want to call. In case there is not, I would suggest you > wrapped the original function in your own project and call the wrapped one > instead. And at last...

Hi Evan, Thanks for your time. You're adding a feature that embed code inside a module. When the module is > loaded, is the string going to be verified? How are users of LLVM IR able > to ensure the embedded string is safe? I am not saying it cannot be done. > This feature just increases the risk and that again raises the bar for > acceptance. > I think the embedded string in

Hello, I run into a situation where I need to provide the library functions, such as sqrt() from <math.h> and rand() from <stdlib.h>, in the format of LLVM IR bitcode files. Then I can try to link the bitcode of my program against these library bitcode files to formulate a holistic bitcode file. However, these library functions are only available in object format. And the source

...could make your GPU project more complete. best regards ether [1]http://en.wikipedia.org/wiki/Heterogeneous_computing [2]http://llvm.org/devmtg/2010-11/Villmow-OpenCL.pdf [3]http://llvm.org/devmtg/2008-08/Sander_HW-SW-CoDesignflowWithLLVM.pdf On Mon, Apr 2, 2012 at 10:16 PM, Yabin Hu <yabin.hwu at gmail.com> wrote: > Hi all, > > I am a phd student from Huazhong University of Sci&Tech, China. The > following is my GSoC 2012 proposal. > Comments are welcome! > > Title: Automatic GPGPU Code Generation for LLVM > > Abstract > Very often, manually developin...

...gt; Thanks very much for your comments. >> >> 2012/4/28 Justin Holewinski <justin.holewinski at gmail.com >> <mailto:justin.holewinski@**gmail.com <justin.holewinski at gmail.com>>> >> >> >> On Fri, Apr 27, 2012 at 7:40 PM, Yabin Hu <yabin.hwu at gmail.com >> <mailto:yabin.hwu at gmail.com>> wrote: >> >> The attached patch adds a new Intrinsic named "llvm.codegen" to >> support embedded LLVM IR code generation. The 'llvm.codegen' >> intrinsic uses the LLVM b...

...[1] Andreas Neustifte, *Efficient Profiling in the LLVM Compiler Infrastructure*, 2010 [2] Matthew Arnold, Stephen Fink, Vivek Sarkar, Peter F. Sweeney, *A Comparative Study of Static and Profile-Based Heuristics for Inlining*, 2000 [3] Pohua P. Chang, Scott A. Mahlke, William Y. Chen, Wen-Mei W. Hwu,*Profile-guided Automatic Inline Expansion for C Programs*, 1992 [4] Karl Pettis, Robert C. Hansen, *Profile Guided Code Positioning*, 1990 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20110330/f08432bb/att...

On Mon, Apr 2, 2012 at 7:16 AM, Yabin Hu <yabin.hwu at gmail.com> wrote: > Hi all, > > I am a phd student from Huazhong University of Sci&Tech, China. The > following is my GSoC 2012 proposal. > Comments are welcome! > > *Title: Automatic GPGPU Code Generation for LLVM* > > *Abstract* > Very often, manually deve...

Hi all, I am a phd student from Huazhong University of Sci&Tech, China. The following is my GSoC 2012 proposal. Comments are welcome! *Title: Automatic GPGPU Code Generation for LLVM* *Abstract* Very often, manually developing an GPGPU application is a time-consuming, complex, error-prone and iterative process. In this project, I propose to build an automatic GPGPU code generation framework

On May 8, 2012, at 2:08 AM, Tobias Grosser wrote: > On 05/08/2012 05:13 AM, Evan Cheng wrote: >> Sorry Tobias, I'm not in favor of this change. From what I can tell, this enables some features which can implemented via other means. It adds all kinds of complexity to LLVM and I'm also highly concerned about bitcode that can embed illegal (or worse malicious) code using this

Where we are ------------ Currently, when we generate OpenMP target offloading code for GPUs, we use sufficient syntactic criteria to decide between two execution modes: 1) SPMD -- All target threads (in an OpenMP team) run all the code. 2) "Guarded" -- The master thread (of an OpenMP team) runs the user code. If an OpenMP distribute region is encountered,

Hi all， Clang use a hash table to store all its identifiers. The hash table definition is: typedef llvm::StringMap<IdentifierInfo*, llvm::BumpPtrAllocator> HashTableTy; HashTableTy HashTable; Can anyone explain the mechnism of handling the name string key collision for me? Is there a IdentifierInfo objects chain or list for variable or function with the same name? Thanks very much!

Hi all, How can I implement a multiple function return values scheme in a performance efficient way, just like what be done in Matlab or Octave? Thanks in advance, Yabin -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20110531/5813e7a6/attachment.html>