similar to: [LLVMdev] Issuing Diagnostics in llvm-ld

Nick Lewycky wrote: > Sanjiv.Gupta at microchip.com wrote: >> >> >> A common followup question is "but how do I link native libraries into >> my .bc file". You don't. A .bc file is llvm ir, you can't put a native >> binary library into a .bc (barring sticking it in as a string, etc). >> >> The build then looks like: >> >>

A common followup question is "but how do I link native libraries into my .bc file". You don't. A .bc file is llvm ir, you can't put a native binary library into a .bc (barring sticking it in as a string, etc). The build then looks like: a) 'llvm-gcc -c -flo -O2' to generate the .bc files. b) 'llvm-ld' to combine them into a single .bc. No, not a .so nor a .a.

Sanjiv Gupta wrote: > Nick Lewycky wrote: >> Sanjiv.Gupta at microchip.com wrote: >>> >>> >>> A common followup question is "but how do I link native libraries into >>> my .bc file". You don't. A .bc file is llvm ir, you can't put a native >>> binary library into a .bc (barring sticking it in as a string, etc). >>>

Sanjiv.Gupta at microchip.com wrote: > > > A common followup question is "but how do I link native libraries into > my .bc file". You don't. A .bc file is llvm ir, you can't put a native > binary library into a .bc (barring sticking it in as a string, etc). > > The build then looks like: > > a) 'llvm-gcc -c -flo -O2' to generate the .bc

On Aug 12, 2009, at 9:48 PM, Sanjiv.Gupta at microchip.com wrote: > Chris, > I will try to get it done before 2.6. (8/21). > Thanks Sanjiv! One other nice cleanup (but which is not time critical at all) would be to merge the contents of "PIC16Section" into the new "MCSectionPIC16" class. Unlike the previous design, you're now allowed to store arbitrary

The driver behaves differently when I run it by specifying absolute path than when I run it with relative path. See example Relative: i00202 at ubuntu:/tmp$ mcc16 --save-temps -dry-run hello.c./clang-cc -I ./include -triple=pic16- -emit-llvm-bc hello.c -o hello.bc-pqDR1Y llvm-ld -link-as-library hello.bc-pqDR1Y -o tmp.bc-M1Rwip llc -march=pic16 -f tmp.bc-M1Rwip -o tmp.s-DcVczP gpasm -I ./inc

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

On Thu, 2008-10-02 at 11:19 -0700, Evan Cheng wrote: > > On Oct 2, 2008, at 11:02 AM, Sanjiv.Gupta at microchip.com wrote: > > > What’s the value produced by an INSERT_SUBREG node? Is it a chain? > > > No, insert_subreg returns a value: > > > v1 = insert_subreg v2, v3, idx > > > v1 and v2 will have the same type, e.g. i16, and v3 must have a >

Mikhail Glushenkov wrote: > Hi Sanjiv, > > 2009/6/23 <Sanjiv.Gupta at microchip.com> > >>> BTW, Chris's Makefile changes broke llvmc yesterday (r75379). I'm >>> working on a fix. >>> >> Hi Mikhail, >> Did you get a chance to fix this. I still get errors while building examples. >> >> > > This issue

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 x86_subreg_16bit : PatLeaf<(i32 2)>; > def x86_subreg_32bit : PatLeaf<(i32 3)>; > > def : SubRegSet<1, [AX, CX, DX, BX, SP, BP, SI, DI, >

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 >

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

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 x86_subreg_16bit : PatLeaf<(i32 2)>; >> def x86_subreg_32bit : PatLeaf<(i32

You need to specify sub-register == super-register, idx relationship. See X86RegisterInfo.td: def x86_subreg_8bit : PatLeaf<(i32 1)>; def x86_subreg_16bit : PatLeaf<(i32 2)>; def x86_subreg_32bit : PatLeaf<(i32 3)>; def : SubRegSet<1, [AX, CX, DX, BX, SP, BP, SI, DI, R8W, R9W, R10W, R11W, R12W, R13W, R14W, R15W], [AL, CL,

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. Some examples illustrating the features you requested: > 2. If the user has specified to generate the final

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

Substituting the uses of a global with an absolute address would make all accesses to that global through pointer, which is very inefficient on PIC16. So we don't change the code generation for that global; instead we only pass the address information to the linker (home made linker) through some assembly directives. What are you trying to do? Are you trying to change the logic of this part or

I found out the problem. Looks like I can not rely on argv[0] to contain the full path of the executable always. Can I rely on: static Path GetMainExecutable(const char *argv0, void *MainAddr); is it Cross-platform? What to pass for second parameter here. C++ forbids taking address of "main", and the "Main" of CompilerDriver is in a shared object here. - Sanjiv Sanjiv

> BTW, Chris's Makefile changes broke llvmc yesterday (r75379). I'm > working on a fix. Hi Mikhail, Did you get a chance to fix this. I still get errors while building examples. i00202 at ubuntu:~/projects/llvm/tools/llvmc/example/mcc16$ make make[1]: Entering directory `/home/i00202/projects/llvm/tools/llvmc/example/mcc16/plugins' make[2]: Entering directory

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