search for: ldw

Hi, During instruction selection, I have the following code for certain LOAD instructions: const LoadSDNode *LD = cast<LoadSDNode>(N); SDNode* LDW = CurDAG->getMachineNode(AVR::LDWRdPtr, SDLoc(N), VT, PtrVT, MVT::Other, LD->getBasePtr(), LD->getChain()); // Honestly, I have no idea what this does, but other memory // accessing instructions have something similar... MachineSDNode::mmo_iterator MemOp =...

...8(%r19) + fstd,ma %fr18,8(%r19) + fstd,ma %fr19,8(%r19) + fstd,ma %fr20,8(%r19) + fstd %fr21,0(%r19) + bv %r0(%rp) + copy %r0,%r28 + .procend + + .text + .align 4 + .global longjmp + .export longjmp, code + .proc + .callinfo +longjmp: + ldw 0(%r26),%r3 + ldw 8(%r26),%r4 + ldw 12(%r26),%r5 + ldw 16(%r26),%r6 + ldw 20(%r26),%r7 + ldw 24(%r26),%r8 + ldw 28(%r26),%r9 + ldw 32(%r26),%r10 + ldw 36(%r26),%r11 + ldw 40(%r26),%r12 + ld...

On 7/29/2017 1:28 AM, Dr. ERDI Gergo via llvm-dev wrote: > Hi, > > During instruction selection, I have the following code for certain > LOAD instructions: > > const LoadSDNode *LD = cast<LoadSDNode>(N); > SDNode* LDW = CurDAG->getMachineNode(AVR::LDWRdPtr, SDLoc(N), > VT, PtrVT, MVT::Other, > LD->getBasePtr(), LD->getChain()); > > // Honestly, I have no idea what this does, but other memory > // accessing instructions have something similar... > MachineSDN...

Hi, I'd like to define a pseudo-instruction whose expansion will, as a side-effect, overwrite an input register's value: the pseudo-instruction ldw r1:r2, P to load 2 bytes from memory address P is to be expaneded to ld r1, P+ ld r2, P where "ld _, P+" is an instruction that loads a single byte from P, and post-increments P by one. How can I represent this behaviour in LLVM? Currently, I have let Constraints = "@earlycl...

...t operate on only the lower 32 bits of each register. So for a basic 'a = b + c' example, we get %0 = load i32, i32* @b, align 4, !tbaa !1 %1 = load i32, i32* @c, align 4, !tbaa !1 %add = add nsw i32 %1, %0 store i32 %add, i32* @a, align 4, !tbaa !1 And we'd want to generate ldw %r0, at b ; load b (32 bits) from memory with sign extension to 64 bits ldw %r1, at c ; load c (32 bits) from memory with sign extension to 64 bits addw %r2,%r0,%r1 ; add lower 32 bits of r0 and r1 stw @a,%r2 ; store lower 32 bits of r2 to a If I define the ldw instruction faithful...

...stead of the low bits, as should happen with truncate. Details: i64 's are stored in two adjacent 32 bit registers. So the store happens like this: "stddw 0xBBBBBBBB33333333, *$ptr" and the load should happen like this: "lddw *$ptr, A5:A4" . It is easy to see that if "ldw *$ptr, A4" is printed, then the high bits will be loaded into A4. Something like this would be correct just like the lddw variant: "ldw *-$ptr(4), A4" Is there a way to change this behavior (that (trunc (load doubleword)) is replaced by (load word))? Or if you think the fault lies...

On Sun, 28 May 2017, David Chisnall wrote: >> let Constraints = "@earlyclobber $reg" in >> def LDWRdPtr : Pseudo<(outs DREGS:$reg), >> (ins PTRREGS:$ptrreg), >> "ldw\t$reg, $ptrreg", >> [(set i16:$reg, (load i16:$ptrreg))]>, >> Requires<[HasSRAM]>; >> >>...

...his would mean to change the TargetData class, which is not meant to be subclassed. > Is there a cleaner solution without modifying llvm? > > Regards, Christian The XCore has loads / stores where the offset is scaled by the size of the load or store. For example the load word instruction LDW takes an offset which is multiplied by 4 and added to the base pointer. This is dealt with in the patterns defined in XCoreInstrInfo.td. The following pattern is used for LDW: def : Pat<(load (add GRRegs:$addr, immUs4:$offset)), (LDW_2rus GRRegs:$addr, (div4_xform immUs4:$offset))&...

...n with truncate. > > Details: i64 's are stored in two adjacent 32 bit registers. So the > store happens like this: > "stddw 0xBBBBBBBB33333333, *$ptr" > and the load should happen like this: > "lddw *$ptr, A5:A4" > . It is easy to see that if > "ldw *$ptr, A4" > is printed, then the high bits will be loaded into A4. Something like > this would be correct just like the lddw variant: > "ldw *-$ptr(4), A4" > > Is there a way to change this behavior (that (trunc (load doubleword)) > is replaced by (load word))? &gt...

...arisc/syscall.S + * + * %r20 contains the system call number, %r2 contains whence we came + * + */ + + .text + .align 64 ; cache-width aligned + .globl __syscall_common + .type __syscall_common,@function +__syscall_common: + ldo 0x40(%sp),%sp + stw %rp,-0x54(%sp) ; save return pointer + + ldw -0x74(%sp),%r22 ; %arg4 + ldw -0x78(%sp),%r21 ; %arg5 + + ble 0x100(%sr2, %r0) ; jump to gateway page + nop ; can we move a load here? + + ldi -0x1000,%r19 ; %r19 = -4096 + sub %r0,%ret0,%r22 ; %r22 = -%ret0 + cmpb,>>=,n %r19,%ret0,1f ; if %ret0 >= -4096UL + ldi -1,%ret0...

Hi, my target architecture has a kind of "16bit addressing mode", i.e. one address does not address 8 bit but a 16bit chunk. Consequently, every constant used to calculate effective addresses must be divided by two. So far this is not such a problem for stack objects since FrameIndexes, function arguments etc. have a lot of custom lowering code where this can be done. But when it comes

The reason the ones in PPCInstrInfo.td don't have the patterns to match is the reason they are more analogous to your problem. Namely, tblgen does not have a way to produce nodes with more than one result. The load-with-update instructions do exactly that - one of the inputs is also an output, but the other output is independent (and necessarily a separate register). The FMA variants have

Thanks. I saw the header comments but it wasn’t clear to me what the difference between those concepts is? My slightly vague understanding is IsDef means that the register specified by this operand is set by the machine instruction. So I understand that to mean the MO will override that register? Also things like early clobber, perhaps there is another document that clarifies some of these

...+) for (j = 0; j < sz - i; j++) if(*(arr+j) > *(arr+j+1)) { int t = *(arr+j); *(arr+j) = *(arr+j+1); *(arr+j+1) = t; } } Part of assemble codes (bubbleSort-gcc-O2.s) from GCC M*Core backend with -O2: .L3: cmplti r3,1 jbt .L6 mov r7,r2 movi r6,0 .L5: ldw r5,(r7) ldw r4,(r7,4) ... .L4: addi r6,1 addi r7,4 cmpne r3,r6 jbt .L5 The address calculating formula for such code is N(0) = arr; N(n) = N(n-1) + ElementSize, n>= 1 which r2 stands for arr, r7 stands for the next address, and ElementSize of int type is 4. However, LLVM GEP adopts a rule...

...o reduce it to the following C function: void foo(int *a) // int here is 16bits { *a &= 0xFF; } This is the code before regalloc: Live Ins: %R25R24 %vreg0<def> = COPY %R25R24; DREGS:%vreg0 %vreg2<def> = COPY %vreg0; PTRREGS:%vreg2 DREGS:%vreg0 %vreg1<def> = LDWRd %vreg2; mem:LD2[%a](align=1)(tbaa=!"int") DLDREGS:%vreg1 PTRREGS:%vreg2 %vreg3<def> = ANDIWRdK %vreg1, 255; DLDREGS:%vreg3,%vreg1 %vreg5<def> = COPY %vreg0; PTRREGS:%vreg5 DREGS:%vreg0 STWRr %vreg5, %vreg3<kill>; mem:ST2[%a](align=1)(tbaa=!"int")...

On 11 January 2017 at 10:24, Jim Grosbach via llvm-dev <llvm-dev at lists.llvm.org> wrote: > ARM64 is like this. I suggest having a look at that backend (lib/Target/AArch64) and how it deals with implicit zeroing of the upper bits of the X registers. ARM64 has a separate name for the registers as 32-bit values though (W0-W30 rather than X0-X30). I could easily see DAG ISel throwing a fit

...TargetData class, which is not meant > to be subclassed. > > Is there a cleaner solution without modifying llvm? > > > > Regards, Christian > The XCore has loads / stores where the offset is scaled by the size of > the load or store. For example the load word instruction LDW takes an > offset which is multiplied by 4 and added to the base pointer. This is > dealt with in the patterns defined in XCoreInstrInfo.td. The following > pattern is used for LDW: > > def : Pat<(load (add GRRegs:$addr, immUs4:$offset)), > (LDW_2rus GRRegs:$addr, (di...

On Tue, 30 May 2017, Nemanja Ivanovic wrote: > This is typically accomplished with something like PPC's `RegConstraint` and > `NoEncode`. You can see examples of it that are very similar to what you're after in > PPC's load/store with update forms (i.e. load a value and update the base register > with the effective address - these are used for pre-increment loads/stores).

...e removed as pointed out above, but since R27R26 is killed in the load instruction it has to be emitted. About the insane amount of regclasses there, the load/store and the andi instructions take subsets of regs from the main register class, they cant work with all registers, that's why STW and LDW needs R27R26 since it belongs to the ptr reg class and not R25R24 where the "a" ptr is. As a test i made the load/store instructions work with the DREGS which is the main class and the problem was solved, but of course this is illegal code :) The coalescer cannot join copies with disjoin...

...rror is introduced because the offset is not calculated correctly. The first problem is that the pointer I get for loading does not point to the address of the low word, but to the address of the high word. The second problem is that this is apparently correct as long as lddw is used instead of ldw. Do you have any ideas on this? (The third problem is that the creation of the pointer is not my doing. I'm just extending our backend to support i64 additionally (instead of just i32 and smaller). Doing this turns out to be trickier than expected.) Cheers, Johannes