similar to: [LLVMdev] support for addressing units which are not 8 bits

On Thu, Jun 20, 2013 at 6:14 AM, Boris Boesler <baembel at gmx.de> wrote: > Hi! > > I want to write a LLVM back-end for a bit addressing target architecture. > > http://llvm.org/docs/GetElementPtr.html#i-m-writing-a-backend-for-a-target-which-needs-custom-lowering-for-gep-how-do-i-do-thisstates quite clearly that some additional work must be done for this sort > of

Hi! Am 05.11.2014 um 16:05 schrieb Tim Northover <t.p.northover at gmail.com>: > Hi Boris, > > On 5 November 2014 06:47, Boris Boesler <baembel at gmx.de> wrote: >> Cross-check: Move the MV-patterns from the beginning to the end. Voila, it works. > > It would be better to delete those patterns entirely. They'll always > match (if asked) and never give a

Hi Quentin, I added some debug output (N->dump()) in ::Select(SDNode*N) and compared it to the dot/Graphviz output (-view-legalize-types-dags; the last one with correct code). I found out, that some SDNodes are not passed to the ::Select(SDNode*N), approximately 11 nodes are missing. The first add-node (v1+v2) is missing. Is it normal that not all nodes are passes to ::Select()? Thanks,

The IR after LSR is: *** IR Dump After Loop Strength Reduction *** ; Preheader: entry: tail call void @fill_array(i32* getelementptr inbounds ([10 x i32], [10 x i32]* @buffer, i32 0, i32 0)) #2 br label %while.body ; Loop: while.body: ; preds = %while.body, %entry %lsr.iv = phi i32 [ %lsr.iv.next, %while.body ], [ 0, %entry ] %uglygep = getelementptr

Hi Quentin, Am 01.11.2014 um 00:39 schrieb Quentin Colombet <qcolombet at apple.com>: > > On Oct 31, 2014, at 11:00 AM, Boris Boesler <baembel at gmx.de> wrote: > >> Hi Quentin, >> >> I added some debug output (N->dump()) in ::Select(SDNode*N) and compared it to the dot/Graphviz output (-view-legalize-types-dags; the last one with correct code). I

Hi Quentin, Am 03.11.2014 um 23:30 schrieb Quentin Colombet <qcolombet at apple.com>: >> Continuing at 4309 >> Match failed at index 4310 >> Continuing at 4322 >> Morphed node: 0x7fef2a033610: i32 = MVrr 0x7fef2a033610 [ORD=21] >> >> >> Does the add operation become a MOVE instruction, or is this a chain of rules? > > Yes, your add becomes

Hi Quentin, yes, this happens quite late. With the Option --debug-pass=Structure it's in or after "Assembly Printer". I do have a very simple DAGToDAGISel::Select() method: SDNode *MyTargetDAGToDAGISel::Select(SDNode *N) { SDLoc dl(N); // default implementation if (N -> isMachineOpcode()) { N -> setNodeId(-1); return NULL; // Already selected. } SDNode

Hi! I'm making a strange observation in my backend, that ends in illegal code: Version 1: - I lower FrameIndex to TargetFrameIndex (nothing special) - I generate a special address-register ADD instruction in eliminateFrameIndex() to write FramePointer + offset into a new address-register - I use explicit load and store and address-registers in my target instruction patterns: eg (store

Hi! I started writing a LLVM backend for a custom architecture. I have some register and instruction .td files and some other files/classes like a MCStreamer for assembler output. At the moment I can compile some empty programs so far. I implemented the method ::eliminateFrameIndex() similar to the Sparc and ARM backend. The method looks like this: // frame pointer is in reg of class

I'm targeting a machine that can only load and store aligned 64-bit words, but I'd like to be able to pack 8-, 16-, and 32-bit values into these words. Loads will require various shifts and masks; stores are more complicated. Does LLVM provide any support for such things? Is there an example target I can look at for ideas? Thanks, Preston -------------- next part -------------- An HTML

It looks like I need to be able to intercept GEP lowering (in SelectionDAGLowering::visitGetElementPtr) and insert something else other than the shifts and adds. The basic problem is that CellSPU loads and stores on 16-byte boundaries. Consequently, the SPU backend has to do the load or store differently than most normal architectures that have byte-addressable operations.

Hi! During my backend development I get the error message for some tests: *** Bad machine code: Virtual register def doesn't dominate all uses. *** (C source-code, byte-code disassembly and printed machine code at the end of the email) The first USE of vreg4 in BB#1 has no previous DEF in BB#0 or #1. But why? I can't see how the LLVM byte-code is transformed to the lower machine code.

ISSUE: This code: %bob = type { int } int %alias() { %pbob1 = alloca %bob %pbob2 = getelementptr %bob* %pbob1 ;pbob2 aliases pbob1 %pbobel = getelementptr %bob* %pbob2, long 0, ubyte 0 %rval = load int* %pbobel ret int %rval } Crashes when run through opt -instcombine. InstCombiner visits instructions in reverse declaration order, but

On Thu, Dec 8, 2011 at 3:29 PM, Ryan Taylor <ryta1203 at gmail.com> wrote: > Ok, thanks, this makes sense. But there is no way to get the SelectionDAG to > do it for me via something like visitGetElementrPtr? SelectionDAGBuilder::visitGetElementPtr uses the same algorithm you want to use, but it is specialized for building a SelectionDAG, which is lower level than LLVM IR. -Eli >

On Aug 28, 2007, at 7:02 AM, Dan Gohman wrote: > On Mon, Aug 27, 2007 at 07:26:55PM -0700, Scott Michel wrote: >> It looks like I need to be able to intercept GEP lowering (in >> SelectionDAGLowering::visitGetElementPtr) and insert something else >> other than the shifts and adds. The basic problem is that CellSPU >> loads and stores on 16-byte boundaries. Consequently,

Hm, no. I expect byte addresses - everywhere. The compiler should not know that the arch needs word addresses. During lowering LOAD and STORE get explicit conversion operations for the memory address. Even if my arch was byte addressed the code would be false/illegal. Boris > Am 09.06.2020 um 19:36 schrieb Eli Friedman <efriedma at quicinc.com>: > > Blindly guessing here,

On Mon, Aug 27, 2007 at 07:26:55PM -0700, Scott Michel wrote: > It looks like I need to be able to intercept GEP lowering (in > SelectionDAGLowering::visitGetElementPtr) and insert something else > other than the shifts and adds. The basic problem is that CellSPU > loads and stores on 16-byte boundaries. Consequently, the SPU backend > has to do the load or store differently

Hi Quentin, >> Yes, the dags in view-isel-dags and view-legalize-types-dags are correct (the add operations are here and are their results are used) and the dags are the same. > > And what about view-sched-dags? The DAG looks like I described below (*) > This one should give you what has been selected. So if this is not correct, you have indeed a problem in the selection

On Aug 28, 2007, at 6:15 PM, Scott Michel wrote: > On Aug 28, 2007, at 7:02 AM, Dan Gohman wrote: > >> On Mon, Aug 27, 2007 at 07:26:55PM -0700, Scott Michel wrote: >>> It looks like I need to be able to intercept GEP lowering (in >>> SelectionDAGLowering::visitGetElementPtr) and insert something else >>> other than the shifts and adds. The basic problem is

Hi everyone I'm hitting an assertion in PHIElimination.cpp:375. "Terminator instructions cannot use virtual registers unless" "they are the first terminator in a block!" I was looking at the code around that location a bit and have not found a reason why this assertion has to hold, except for a comment: // In our final twist, we have to decide which instruction