similar to: [LLVMdev] Overhauling the command-line processing/codegen options code

Reply to list as I had originally intended... ---------- Forwarded message ---------- From: Justin Holewinski <justin.holewinski at gmail.com> Date: Wed, Feb 13, 2013 at 4:23 PM Subject: Re: [LLVMdev] Overhauling the command-line processing/codegen options code To: Chris Lattner <clattner at apple.com> On Wed, Feb 13, 2013 at 3:53 PM, Chris Lattner <clattner at apple.com>

Is anyone currently working on overhauling the command-line processing code? We're currently having some design issues with this component, and I'd like to start a larger conversation on it. For context, I am talking from an "LLVM as a library" perspective instead of an "LLVM as a set of tools" perspective. In a nut-shell, the problems we are facing are as follows:

On Feb 13, 2013, at 2:32 PM, Justin Holewinski <justin.holewinski at gmail.com> wrote: > > This is a very interesting one that is orthogonal to Bill's work. The preferred approach for this sort of thing is to change the LoopUnroll pass to take the unroll threshold as a constructor argument or a struct that wraps up all of the configuration settings. When the pass is *default*

Hi, I'm a contributor to the KLEE project (based on LLVM) and I'm currently looking at trying to add the following functionality to KLEE... (1). Be able to iterate through registered command line options and programmatically hide them. We're interested in this because we wish to hide (unless -help-hidden is called) several LLVM options. (2). Be able to place an option into a category

Justin Holewinski <justin.holewinski at gmail.com> writes: > I believe the point Tobias is trying to make is that he wants to > retain the ability to pipe modules between tools and not worry about > the modules ever hitting disk, e.g. > > opt -load GPUOptimizer.so -gpu-opt | llc -march=x86 > where the module coming in to opt is just unoptimized host code, and the module

On Tue, May 1, 2012 at 8:22 AM, <dag at cray.com> wrote: > Justin Holewinski <justin.holewinski at gmail.com> writes: > > > I don't think the code base changes are all that bad. We have a > number > > of them to support generating code one function at a time rather > than a > > whole module together. They've been sitting around

Right, I'm suggesting we keep llvm_shutdown() for users who want this control, but also destroy still-live ManagedStatic instances if llvm_shutdown() is not called. This helps in the case where there is not a clear time when llvm_shutdown() can be called, especially given that LLVM cannot be resurrected in the same process due to current limitations in the pass registry, and perhaps

Justin Holewinski <justin.holewinski at gmail.com> writes: > I don't think the code base changes are all that bad. We have a number > of them to support generating code one function at a time rather than a > whole module together. They've been sitting around waiting for us to > send them upstream. It would be an easy matter to simply annotate each >

I'm curious about the design rationale for how ManagedStatic instances are cleaned up, and I'm hoping someone can shed some light on it. Currently, ManagedStatic objects are cleaned up when llvm_shutdown() traverses the global list of initialized objects and calls destroy() on each. This leads to two questions: 1. An assertion enforces that the objects are deleted in reverse order of

On Tue, May 8, 2012 at 9:29 AM, <dag at cray.com> wrote: > Tobias Grosser <tobias at grosser.es> writes: > > > So why the intrinsic? I want to create the PTX string from an LLVM-IR > > optimizer pass, that should be loaded into clang, dragonegg, opt, .. > > You want to codegen in the optimizer? I'm confused. > > An LLVM-IR optimizer pass does not

Justin Holewinski <justin.holewinski at gmail.com> writes: > For something like PTX, runtime calls take care of the call semantics so > it is either up to the user or the frontend to set up the runtime calls > correctly. We don't need to completely solve this problem. Yet. :) > > But there has to be some interface that allows an LLVM IR function > from

On Tue, Dec 17, 2013 at 10:31:31AM +0000, Daniel Liew wrote: > Hi, > > We're currently upgrading KLEE to work with LLVM >=3.3 and we've hit a problem. > > It seems r172749 removed support for linking a bitcode archive into a > module. KLEE unfortunately depends on this to link in its runtime ( > which amongst other things provides a C library [5] ). > > A

On Thu, Dec 8, 2011 at 11:36 AM, Villmow, Micah <Micah.Villmow at amd.com>wrote: > It is my understanding that all you need to do is specify let isTarget = > 1 in your .td file and it will generate target specific intrinsics. This > should allow you to keep the IntrinsicsPTX.td file in the same location. > So we keep the intrinsics defined in include/llvm/IntrinsicsPTX.td?

----- Original Message ----- > From: "Justin Holewinski" <justin.holewinski at gmail.com> > To: "Hal Finkel" <hfinkel at anl.gov> > Cc: "David A. Greene" <dag at cray.com>, "LLVM Developers Mailing List" <llvmdev at cs.uiuc.edu> > Sent: Friday, January 11, 2013 2:19:01 PM > Subject: Re: [LLVMdev] Documentation of

On Sun, Dec 4, 2011 at 1:10 PM, Alberto Magni <alberto.magni86 at gmail.com>wrote: > Hi Justin, > > sorry for the delay, I have been busy. > > Micah's proposal requires to move the definitions of the intrinsics > from include/llvm/IntrinsicsPTX.td to lib/Target/PTX/PTXIntrinsics.td > thus allowing the generation of the file PTXGenIntrinsics.inc which > will be

It is my understanding that all you need to do is specify let isTarget = 1 in your .td file and it will generate target specific intrinsics. This should allow you to keep the IntrinsicsPTX.td file in the same location. Micah From: Justin Holewinski [mailto:justin.holewinski at gmail.com] Sent: Monday, December 05, 2011 6:13 AM To: Alberto Magni Cc: Villmow, Micah; LLVM Developers Mailing List

On Tue, Apr 30, 2013 at 12:48 AM, Guo, Xiaoyi <Xiaoyi.Guo at amd.com> wrote: > Hi,**** > > ** ** > > We’ve recently encountered a problem in our compiler where the line number > in debug info jumps back and force even at O0. This is caused by DAG node > ordering not being properly kept during legalization and instruction > selection. There are still uncaught cases

Hi Eric, Sorry I wasn't clear. The problem happened in the "source" pre-RA scheduler, which relies on DAG node ordering to schedule the nodes. Xiaoyi From: Eric Christopher [mailto:echristo at gmail.com] Sent: Tuesday, April 30, 2013 12:54 AM To: Guo, Xiaoyi Cc: LLVM Developers Mailing List Subject: Re: [LLVMdev] [PATCH] Propagate DAG node ordering during legalization and

Here''s the scenario. I have a main tree-like table (actually it''s more of a hierarchy), where the entries (or at least some of them) can be categorised as one or more of a fixed number of types (prob about 6 poss types). So an entry could be a Type A and a Type D; a Type C, D, E; just a Type F; etc. Having a join table would seem like it might get rather expensive since

Does this count have to be exact, or just an accurate approximation? The back-end may add/remove registers fairly late in the codegen process, so if you need an exact count you may need to run *just* before the assembly printer. Perhaps we could introduce a special machine node that represents a shared memory allocation. The node's value would be the shared address space pointer of the