similar to: [LLVMdev] Newbie: Target Lowering info.

On Nov 24, 2007, at 7:28 PM, Sanjiv Gupta wrote: > Could anybody guide me what information do I need to know about my > target in order to provide the target lowering info to the llvm DAG > generator? We do not have any fixed registers for argument passing. > Everything including the formal and actual arguments will take part in > a global interprocedural regalloc. You don't

thanks Evan, I have just started writing td files. Any ideas how do I describe instructions for an accumulator based machine. The other pecularity is that we do not want to have any software stack. So the instructions like load and store have no meanings. In that case, how do I lower instructions that operate on stack frame? TIA, Sanjiv On 11/26/07, Evan Cheng <evan.cheng at apple.com>

On 11/23/07, Fernando Magno Quintao Pereira <fernando at cs.ucla.edu> wrote: > > > Hi, Sanjiv, > > those passes operate on the whole machine function. Each machine > function contains many basic blocks. If a program has many functions, the > register allocator will be called as many times, i.e it does not do > interprocedural allocation. > > best, > >

Thanks again. One more question here: Since the regalloc works once per function, do I stil have access to the Call graph? Just saving information between regalloc passes for different functions may not be enough for my case. I will need to maintain the regalloc info of various passes in the call graph order. Anyways thanks for your inputs. I will get back if I need to learn more. Sanjiv On Nov

Hi, again, I think you can do it in the same way that the other allocators have been coded, i.e extend RA, register the pass and so forth. I am not sure about the best way to pass information among a run of RegAlloc to the other, maybe the other guys in the list could suggest something. Yet, you can always dump it into a file, and read it again, everytime it is necessary. Remember that

As far as I understand , the regalloc passes provided operate on basic block level? Is there anything that operate on the whole Module? Thx, Sanjiv -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20071122/0b24c954/attachment.html>

Hi, Sanjiv, those passes operate on the whole machine function. Each machine function contains many basic blocks. If a program has many functions, the register allocator will be called as many times, i.e it does not do interprocedural allocation. best, Fernando > As far as I understand , the regalloc passes provided operate on basic block > level? > Is there anything that

Dan Gohman wrote: > Hello, > > Attached is a patch which significantly reworks how calls, incoming > arguments, and outgoing return values are lowered. It's a major change, > affecting all targets, so I'm looking for feedback on the approach. > > The goal of the patch is to eliminate a bunch of awkward code, > eliminate some unnecessary differences between targets,

Ours is an accumulator based architecture. So one operand of ADD/SUB operations is in REG (accumulator) and the other one is in Memory. The result can be left either in REG or memory. The LLVM DAG for such operations expect both operands in REG. for example: char a, b, c, d, e; a = (b - c) + (d - e); generates addc:i8 (subc:i8(b,c), subc:i8(d,e)) Looks like we need to custom lower addc

In our case, storeRegToStackSlot, loadRegFromStackSlot clobbers some other physical register which may be holding a live value used somewhere else. How do I make regalloc aware so that it saves the value before storeRegToStackSlot and make it available again at the point of earlier use? TIA, Sanjiv -------------- next part -------------- An HTML attachment was scrubbed... URL:

On Nov 10, 2008, at 9:51 AM, sanjiv gupta wrote: > Ours is an accumulator based architecture. > > So one operand of ADD/SUB operations is in REG (accumulator) and the > other one is in Memory. The result can be left either in REG or > memory. > > The LLVM DAG for such operations expect both operands in REG. > > for example: > char a, b, c, d, e; > a = (b - c) +

Pointer size on our target is 16-bits, and we have two 16-bit registers that can be used only to hold pointers (indirect addresses). All operations on the target are 8-bit operations, so it takes two 8-bit loads to load these pointer registers. We want LLVM to automatically expand all types to 8-bit values. The problem is that LLVM does not expand GlobalAddresses, which are 16-bit

On Thu, 2008-10-23 at 11:17 -0700, Evan Cheng wrote: > > On Oct 22, 2008, at 11:09 AM, Sanjiv.Gupta at microchip.com wrote: > > > In our case, storeRegToStackSlot, loadRegFromStackSlot clobbers some > > other physical register which may be holding a live value used > > somewhere else. How do I make regalloc aware so that it saves the > > value before

> > I don't think there is code in Legalizer to expand GlobalAddress. But you > can custom lower it. X86 custom lower GlobalAddress nodes for a different > reason. > > Evan > Hmmm...That means we have to make i16 as a legal type (since GlobalAddresses are 16-bits) and custom lower all 16-bit operations to 8-bit operations. I was thinking to take advantage of the

On Oct 22, 2008, at 11:09 AM, Sanjiv.Gupta at microchip.com wrote: > In our case, storeRegToStackSlot, loadRegFromStackSlot clobbers some > other physical register which may be holding a live value used > somewhere else. How do I make regalloc aware so that it saves the > value before storeRegToStackSlot and make it available again at the > point of earlier use? >

I can't say this is a bug it is changed behavior from before the new attribute scheme. This issue may appear with other attributes. (there are other attributes that clang will now place on each function) If you run clang as a single pass to create a .ll and don't say -msoft-float, it puts the attribute use-soft-float=false on every function. (It used to be that in that case

Hello, Attached is a patch which significantly reworks how calls, incoming arguments, and outgoing return values are lowered. It's a major change, affecting all targets, so I'm looking for feedback on the approach. The goal of the patch is to eliminate a bunch of awkward code, eliminate some unnecessary differences between targets, and to facilitate future refactoring and feature work.

Note: Question is written after describing what I have coded. Hello LLVMDevs, I am trying to impliment floating point comparsion for an architecture which supports following type of floating point comparision if FPU is available: fcmp.un --> true if one of the operand is NaN fcmp.lt --> ordered less than, if any input NaN then return false fcmp.eq --> ordered equal, if any input NaN

For lowering llvm.memcpy.* etc SelectionDAG::getMemcpy generates a libcall to "memcpy" as a last resort. See the code snippets below. // FIXME: pass in DebugLoc std::pair<SDValue,SDValue> CallResult = TLI.LowerCallTo(Chain, Type::VoidTy, false, false, false, false, 0, CallingConv::C, false, getExternalSymbol("memcpy",

I've found that I need to set the -pre-RA-sched parameter when using tools like llc to get the kind of instruction scheduling I want. However I'm normally generating and running code on the fly using the JIT, and can't figure out how to set the -pre-RA-sched option anywhere other than on the command line for the provided tools. So what code would I write (or where is the API?) to