similar to: [LLVMdev] disabling combining load/stores in optimizer.

On Aug 2, 2009, at 11:08 PM, Sanjiv.Gupta at microchip.com wrote: > Consider writes to a struct {i32 a; i32 b}; > > The optimizer can currently combine stores (i32, i32) to a single > i64 store operation. Is there a way to disable that? Not currently. There are some ideas floating around about including in TargetData a list of integer types that the target natively supports, which

> > The optimizer can currently combine stores (i32, i32) to a single > > i64 store operation. Is there a way to disable that? > > Not currently. There are some ideas floating around about > including in TargetData a list of integer types that the > target natively supports, which would allow instcombine > and other passes to make more informed decisions, but > at

> > So I think it should be at the discretion of port to enable or disable > > such optimizations as needed. > > While that it a valid approach in general, it is completely at odds > with the approach that the LLVM codebase has taken. The general LLVM > philosophy is that all optimizations should be as aggressive as > possible at whatever they do, and it is then the

On Aug 3, 2009, at 1:20 PM, Alireza.Moshtaghi at microchip.com wrote: >> >>> I feel that such optimizations may not result in any gain for PIC16 >>> >>> as PIC16 does everything on i8. >>> >> >> >> The legalize pass should turn an i64 store into 8 i8 stores >> >> then, which is essentially the same as what an {i32,i32} store

On Aug 4, 2009, at 9:51 AM, Alireza.Moshtaghi at microchip.com wrote: > >>> So I think it should be at the discretion of port to enable or > disable >>> such optimizations as needed. >> >> While that it a valid approach in general, it is completely at odds >> with the approach that the LLVM codebase has taken. The general LLVM >> philosophy is that

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

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

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

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

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.

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

PIC16 does not want globals marked with section attributes being deleted. But I see llvm-ld removes them even if the user marks them as "volatile".I wonder why? - Sanjiv

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

Chris, I will try to get it done before 2.6. (8/21). - Sanjiv -----Original Message----- From: llvmdev-bounces at cs.uiuc.edu on behalf of Chris Lattner Sent: Wed 8/12/2009 10:08 PM To: LLVM Developers Mailing List Subject: [LLVMdev] XCore & PIC16 AsmPrinters Hi XCore and PIC16 maintainers, I'd appreciate it if you guys could move your AsmPrinter implementation to be in a

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

Hi Sanjiv, The PIC16TargetAsmInfo::getBSSSectionForGlobal apparently does magic that reinterprets the "section" field of a global in a strange way: // If GV has a sectin name or section address create that section now. if (GV->hasSection()) { std::string SectName = GV->getSection(); // If address for a variable is specified, get the address and create

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 >

PIC16 now has clang and llc based system to generate native assembly. We then use our native assembler (gpasm) and the native linker (mplink) to generate the final executable. How can I integrate these things with the driver llvmc to have gcc like user experience? Note that we also want to run llvm-ld in order to perform the LTOs in case of multiple files. - Sanjiv