similar to: [LLVMdev] Generating individual SDValue

Hi there, I am doing relocation in my backend by calling my function getAddrNonPic: SDValue getAddrNonPIC(NodeTy *N, SDLoc DL, EVT Ty, SelectionDAG &DAG)const{ SValue Hi=getTarget(N,Ty,DAG, MyBackend::Hi16); SValue Lo=getTarget(N,Ty,DAG, MyBackend::Lo16); return DAG.getNode(ISD::ADD, DL, Ty, DAG.getNode(MyBackend::Hi16, DL, Ty, Hi), DAG.getNode(MyBackend::Lo16, DL, Ty, Ho)); }

On Jul 20, 2009, at 4:18 PM, Alireza.Moshtaghi at microchip.com wrote: > 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

Please read below: > > - Save /all/ registers, including those that are normally caller > > saved. > > - Use a special return instruction (RETI). > > - Step over the "red zone" on the stack. > > - Set up a safe stack frame before calling normal functions. > > > > I usually write the first level interrupt handler in assembler, and > > then

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

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

Our 8-bit port for PIC16 has taken roughly about 18 months to get to where we are now. Our instruction set is not orthogonal, data memory is banked, program memory is paged, there is only one accumulator and two pointer registers, and the use of indirect memory access is really expensive. So we had to implement some non conventional approaches to get the model working. For the most part, LLVM

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

Extended thanks to the llvm community for feedback in advance, and especially thanks to Jim for laying out a solution that captures all aspects of the problems that we are facing. After some discussions with our team, we have decided to do the following, but to avoid further conflict with llvm standards, I would like to get the blessing of llvm community, and in particular, Chris who at some point

Evan, The machine is 8 bit, and of course all registers are 8-bit too. Memory access on this machine is a bit different. The memory is banked into banks of 256-byte, and you can select the active bank using a bank select register. All instructions can access the memory with an 8-bit operand, so in that sense the address space can be viewed as 256-byte long. On the other hand, there are three

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

Hi Ali, Thanks for bringing this up. You're definitely under very tight design constraints from the hardware. I can certainly sympathize. I think two design elements are being conflated here, and it would be worthwhile splitting them out. For correctness, you need to make sure any routines called from an ISR don't clobber equivalent routines called from mainline code. For

On 24/07/2009, at 19.41, <Alireza.Moshtaghi at microchip.com> wrote: > As you know PIC16 does not have stack; so generating code for ISR and > all functions that it calls (including all stdlib and basic math > intrinsics used for mult/div/etc) requires special code generation > techniques. But we don't have this information until after llvm-ld has > merged all compilation

I am trying to verify the generated DAG after converting from llvm to DAG, however I'm not sure if this is correct or not. Here is the situation: In order to get LLVM to lower to 8-bit I have to define only 8-bit registers and the pointer size also to be 8-bit. Doing so, the attached DAG is generated for a load:i16. I have problem understanding this DAG in two places: 1)As you can see the

On Wed, May 20, 2009 at 5:26 PM, Eli Friedman <eli.friedman at gmail.com> wrote: > On Wed, May 20, 2009 at 4:55 PM, Dan Gohman <gohman at apple.com> wrote: >> Can you explain why you chose the approach of using a new pass? >> I pictured removing LegalizeDAG's type legalization code would >> mostly consist of finding all the places that use TLI.getTypeAction

Attached please find the gdb backtrace dump and the postscript file of the DAG right before assertion. The red Node is the current Node in LegalizeOp() The only thing that I am customizing before we get here is the FORMAL_ARGUMENTS. At this time I don't really care about the arguments, just want to get some global values working. When I trace the program, it is well passed the legalizing of

Hello, I'm working in adding support for 64-bit integers to my target. I'm using LLVM to decompose the 64-bit integer operations by using 32-bit registers wherever possible and emulating support where not. When looking at the bit shift decomposition I saw what seems to be a bug in the implementation. The affected function is ExpandShiftWithUnknownAmountBit in LegalizeIntegerTypes.cpp.

On Oct 8, 2007, at 3:15 PM, Alireza.Moshtaghi at microchip.com wrote: > I am trying to verify the generated DAG after converting from llvm to > DAG, however I'm not sure if this is correct or not. > Here is the situation: > In order to get LLVM to lower to 8-bit I have to define only 8-bit > registers and the pointer size also to be 8-bit. > Doing so, the attached DAG is

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

Richard Pennington wrote: > My target doesn't support 64 bit arithmetic, so I'd like to supply > definitions for adde/addc. The problem is I can't seem to figure out the > magic. Here's an example of what I need to generate: > > # two i64s in r5/r6 and r7/r8 > # result in r1/r2, carry in r3 > > # adde > add r2, r6, r8 > cmpltu r3, r2, r6 #

Hi all, While I test "clang-tests/gcc-4_2-testsuite/src/gcc.c-torture/execute/20020226-1.c", I faced something wrong with "DAGCombiner::MatchRotate" function. This function tries to consume some patterns and generate "ROTL" or "ROTR" dag node as following comments: "DAGCombier::MatchRotate" function in DAGCombiner.cpp Pattern1 // fold (or