similar to: [LLVMdev] Generating executable by llc.

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 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? > > ...

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 >> >

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

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

Mikhail Glushenkov wrote: > Hi Sanjiv, > > On Sun, Sep 6, 2009 at 8:13 PM, Mikhail > Glushenkov<the.dead.shall.rise at gmail.com> wrote: > >> Hi Sanjiv, >> >> On Sun, Sep 6, 2009 at 8:07 PM, Mikhail >> Glushenkov<the.dead.shall.rise at gmail.com> wrote: >> >>> [...] >>> >> [Sorry, the formatting was a

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? And how to make sure that we have same behavior on Windows as far as paths (/ Vs \) and picking up tools from the driver directory is concerned? Do I need to write some C++ code to customize such

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? ... because it just disables optimization passed. It does not disable linking. ? - Devang

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 only. But why the cmp libcalls have to > return a 32-bit value. > e.g. Our libcall for

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 only. But why the cmp libcalls have to return a 32-bit value. e.g. Our libcall for comparing two floats is char _eq_f32 (float a, float b); rather than long

Mikhail Glushenkov wrote: > > Hi Sanjiv, > > Sanjiv Gupta <sanjiv.gupta <at> microchip.com> writes: > > > The salient features that we want to have in the driver are: > > [...] > > As promised, I've implemented a basic compiler driver for the > PIC16 toolchain. It's under tools/llvmc/examples/mcc16. > Hi Mikhail, How do you build mcc16

Mikhail Glushenkov wrote: > 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 >

On Tue, 2008-09-23 at 13:33 +0100, Richard Osborne wrote: > sanjiv gupta wrote: > > I have a question: > > In the pattern below from X86 > > > > def INC8r : I<0xFE, MRM0r, (outs GR8 :$dst), (ins GR8 :$src), > > "inc{b}\tdst", > > [(set GR8:$dst, (add GR8:$src, 1))]>; > > > > Since we are emitting only "inc $dst",

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, 2008-10-15 at 10:08 -0700, Evan Cheng wrote: > On Oct 15, 2008, at 5:29 AM, sanjiv gupta wrote: > > > On Tue, 2008-10-14 at 10:19 -0700, Evan Cheng wrote: > >> You need to specify sub-register == super-register, idx relationship. > >> See X86RegisterInfo.td: > >> > >> def x86_subreg_8bit : PatLeaf<(i32 1)>; > >> def