similar to: [LLVMdev] Retrieving local variable names.

Is this something that will happen in future? Or there is no plan for it? Thanks, Ali -----Original Message----- From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Evan Cheng Sent: Wednesday, April 02, 2008 10:30 AM To: LLVM Developers Mailing List Subject: Re: [LLVMdev] Retrieving local variable names. It's not currently available. LLVM would have to

It's not currently available. LLVM would have to propagate debug information through all codegen passes but it doesn't do that yet. Evan On Apr 1, 2008, at 11:02 PM, Sanjiv Gupta wrote: > The code generator converts a local variable into FrameIndex. Is > there anyway I can retrieve the symobl name of the local variable > from FrameIndex? > > Thanks, > Sanjiv >

On Apr 2, 2008, at 1:33 PM, Alireza.Moshtaghi at microchip.com wrote: > Is this something that will happen in future? Or there is no plan for > it? I am not aware of any plan to add this. I suspect this won't happen until there is a major push to improve debugging support. If you are interested in this area, feel free to contribute! :-) Evan > > > Thanks, > Ali >

Chris Lattner wrote: > On Feb 9, 2010, at 7:39 PM, Sanjiv Gupta wrote: > > >> Hi, >> I need to add switches like -disable-mem2reg, disable-gvn to llvm-ld. >> Currently CreateStandardLTOPasses takes in only DisableInternalize and >> DisableInliner switches. >> >> Is modifying this API okay for these new switches, or is it doable in >> some

Dan Gohman wrote: > Have you ever investigated the following approach? Define fake > register+register forms of common instructions, in addition to the > register+memory forms. Let the instruction selector work as if > everything were in registers. Then, since there's only one physical > register, the register allocator will have to spill, and the spills > and reloads can

Sanjiv Gupta wrote: > Sanjiv Gupta wrote: > >> Duncan Sands wrote: >> >> >>> Hi Sanjiv, I think a lot of the softening code assumes you are dealing >>> with float (32 bits). So it's not just a matter of changing the libcall >>> return type. >>> >>> >>> >> Yes, we are dealing with 32-bits

On Mon, 2009-10-05 at 16:54 -0700, Eli Friedman wrote: > On Mon, Oct 5, 2009 at 11:11 AM, Sanjiv Gupta > <sanjiv.gupta at microchip.com> wrote: > > Sanjiv Gupta wrote: > >> Sanjiv Gupta wrote: > >> > >>> Duncan Sands wrote: > >>> > >>> > >>>> Hi Sanjiv, I think a lot of the softening code assumes you are

Mikhail Glushenkov wrote: > Hi Sanjiv, > > 2009/6/18 Sanjiv Gupta <sanjiv.gupta at microchip.com>: > >> Hi Mikhail, >> Thanks for your wonderful help so far. I have few more questions to ask: >> >> How do I modify the driver to pick tools from where the driver itself >> resides, rather than from the PATH? >> Do I need to write some C++ code

On Mon, Oct 5, 2009 at 11:11 AM, Sanjiv Gupta <sanjiv.gupta at microchip.com> wrote: > Sanjiv Gupta wrote: >> Sanjiv Gupta wrote: >> >>> Duncan Sands wrote: >>> >>> >>>> Hi Sanjiv, I think a lot of the softening code assumes you are dealing >>>> with float (32 bits).  So it's not just a matter of changing the libcall

On Tue, Jun 16, 2009 at 2:35 AM, Sanjiv Gupta<sanjiv.gupta at microchip.com> wrote: > What if my global variable was into a different address space than stack? It doesn't matter in terms of semantics: because AnalyzeGlobal returned false, we're guaranteed the address of the global is never taken. I wouldn't be surprised if we end up generating invalid IR in some cases,

On Wed, 2009-07-15 at 10:37 -0700, Devang Patel wrote: > On Wed, Jul 15, 2009 at 9:32 AM, sanjiv gupta<sanjiv.gupta at microchip.com> wrote: > > Consider the example command line below > > > > $ llvm-ld -disable-opt hello.bc -l std -o hello.out > > > > Why does -disable-opt links in all the bitcode from the libstd.so into > > hello.out? > > ...

Hi Sanjiv, Sanjiv Gupta <sanjiv.gupta <at> microchip.com> writes: > > Hi Mikhail, > > I have one more problem related to driver/llvm-ld at my hand for which i > could not think of any solution. May be you can help. > [...] > > Is this possible in driver? or should I hack llvm-ld? On second thought, I think I'll add a workaround for this even if

On Wed, Jul 15, 2009 at 7:29 PM, sanjiv gupta<sanjiv.gupta at microchip.com> wrote: > On Wed, 2009-07-15 at 10:37 -0700, Devang Patel wrote: >> On Wed, Jul 15, 2009 at 9:32 AM, sanjiv gupta<sanjiv.gupta at microchip.com> wrote: >> > Consider the example command line below >> > >> > $ llvm-ld -disable-opt hello.bc -l std -o hello.out >> >

On Feb 10, 2010, at 9:17 PM, Sanjiv Gupta wrote: > Dan Gohman wrote: >> Have you ever investigated the following approach? Define fake >> register+register forms of common instructions, in addition to the >> register+memory forms. Let the instruction selector work as if >> everything were in registers. Then, since there's only one physical >> register, the

Hi Mikhail, I have one more problem related to driver/llvm-ld at my hand for which i could not think of any solution. May be you can help. We use llvm-ld as a linker to link .bc alongwith other .bc libs. example $ llvm-ld foo.bc -l std -o tmp.bc Now this command generates two files 1. tmp.bc (lli executable script) 2. tmp.bc.bc (the linked output .bc) Now i am interested only in

Hi Sanjiv, 2009/6/29 Sanjiv Gupta <sanjiv.gupta at microchip.com>: > I want to retrieve the value of argv[0] (which was passed to main function > of the driver) in PrependCustomizedPath. I've added a way to access argv[0] in hooks: http://thread.gmane.org/gmane.comp.compilers.llvm.cvs/50789 -- () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against

The code excerpt is from IPO/GlobalOpt.cpp // If this is a first class global and has only one accessing function // and this function is main (which we know is not recursive we can make // this global a local variable) we replace the global with a local alloca // in this function. // // NOTE: It doesn't make sense to promote non single-value types since we // are

Mikhail Glushenkov wrote: > Hi, > > On Thu, Sep 10, 2009 at 8:01 PM, Sanjiv Gupta > <sanjiv.gupta at microchip.com> wrote: > >> Why do we need both 'conflict' and 'warning' ? >> > > 'warning' just prints a warning, 'conflict' is a fatal error. > > A better example would be something like: > > (warning (and

Hi Sanjiv, On Wed, Jul 1, 2009 at 7:02 PM, Sanjiv Gupta<sanjiv.gupta at microchip.com> wrote: > I found out the problem. Looks like I can not rely on argv[0] to contain the > full path of the executable always. Yeah, that's what I was thinking. > Can I rely on: > static Path GetMainExecutable(const char *argv0, void *MainAddr); Clang relies on it. According to

Mikhail Glushenkov wrote: > Hi Sanjiv, > > 2009/6/15 Sanjiv Gupta <sanjiv.gupta at microchip.com>: > >> Hi Mikhail, >> How do you build mcc16 executable? >> > > This should work: > > $ cd $LLVM_DIR/tools/llvmc/examples/mcc16 > $ make > > I configure llvm into a separate directory from source. When I do the steps you mentioned in