search for: globaladdr

Hi David, > [(set GR32:$rD, globaladdr:$addr)] > It seems to have somehow managed to create a cycle in the DAG, which is > of course wrong. But how? When I write a similar pattern into the ARM .td files and look at (from the build directory) lib/Target/ARM/ARMGenDAGISel.inc, I see: /*56478*/ /*SwitchOpcode*/ 13, TARGET_VAL(IS...

On 8 March 2014 00:53, Owen Anderson <resistor at mac.com> wrote: > ISDOpcodes.h contains what documentation there is on the semantics of each > opcode. And TargetOpcodes.h for a few of the post-ISel ones (mostly they're in MachineInstr form, but you'll see them with -view-sched-dags, and occasionally before). Tim.

Hi All, In SVN head, MipsISelDAGToDAG.cpp has the following optimization: // Operand is a result from an ADD. if (Addr.getOpcode() == ISD::ADD) { // When loading from constant pools, load the lower address part in // the instruction itself. Example, instead of: // lui $2, %hi($CPI1_0) // addiu $2, $2, %lo($CPI1_0) // lwc1 $f0, 0($2) // Generate: //

...= 1, Defs = [R0, R1, R2, R3, R12, LR, D0, D1, D2, D3, D4, D5, D6, D7, CPSR] in { def ARM_ATOMIC_CMP_SWAP : ABXI<0b1011, (outs GPR:$dst), (ins i32imm:$ptr, i32imm:$old, i32imm:$new), "do_something", [(set GPR:$dst, (atomic_cmp_swap_32 globaladdr:$ptr, imm:$old, imm:$new))]>; } What I want to achieve first is that llc picks this definition when it finds an occurance of the @atomic.cmp.swap.i32 intrinsic. Therefore I wrote a basic .ll file containing only a call to this function. I then let it run through "llvm-as | llc". Wit...

Hi Dan, If you set the node's action to "Custom", you should be able to interfere in the type legalisation phase (before it gets promoted to a 64-bit MUL) by overriding the "ReplaceNodeResults" function. You could either expand it to a different libcall directly there, or replace it with a target-specific node (say XXXISD::MUL32) which claims to take i64 types but you

...0x23aff60: i64 = <<Unknown Node #192>> [ID=-3] 0x23b0260, 0x23b0160 0x23b0260: i64 = and [ID=-3] 0x23af660, 0x23b0060: i64 = Constant<4294967295> [ID=-3] 0x23af660: i64,ch = load<LD4[@i], anyext from i32> [ID=-3] 0x238b068: ch = EntryToken [ID=-3], 0x23ac7d0: i64 = GlobalAddr\ ess<i32* @i> 0 [ID=-3], 0x23ac9d0: i64 = undef [ID=-3] 0x23b0160: i64 = and [ID=-3] 0x23afc60, 0x23b0060: i64 = Constant<4294967295> [ID=-3] 0x23afc60: i64,ch = load<LD4[@j], anyext from i32> [ID=-3] 0x238b068: ch = EntryToken [ID=-3], 0x23acbd0: i64 = GlobalAddr\ ess&l...

Hi, I am missing atomic operations support for the ARM backend (see PR #3887) and started trying to implement them. Since this is the first time that I work on such stuff (and llvm) I am going to take the supposedly easy route and provide an implementation that will work on Linux systems. This involves calling a special function which the kernel handles itself. Details here:

Thanks for the information, allow maybe I can re-phrase the question or issue. Assume 64-bit register types, but integer is 32-bit. Already have table generation of the 64-bit operation descriptions. How about this modified approach? Before type-legalization, I'd really like to move all MUL I64 to a subroutine call of my own choice. This would be a form of customization, but I want this

...poff, $dst", [(set GPRC:$dst, (XSTGRELADDR i64:$spoff, (i64 (XSTGMVINI i64:$addr)) ) )]>; } GlobalAddresses get lowered to RelAddr nodes in our ISelLowering code. Now I just need to be able to expand this in our overridden expandPostRAPseudo function, however, I'm a bit worried that expansion happens too late (after things should already be MI's, it seems). So things like patterns that try t...

...tructions work on all registers: def GR : RegisterClass<"Bfin", [i32], 32, [R0, R1, R2, R3, R4, R5, R6, R7, P0, P1, P2, P3, P4, P5, SP, FP, I0, I1, I2, I3, M0, M1, M2, M3, B0, B1, B2, B3, L0, L1, L2, L3]>; For instance, I can load an arbitrary 32-bit constant or globaladdr/externalsym into any register: def LOAD32imm: Pseudo<(outs GR:$dst), (ins i32imm:$src), "$dst.H = HI($src); $dst.L = LO($src);", [(set GR:$dst, imm:$src)]>; I think I am stretching the code generator beyond its capability by doing this....

I've been looking at GlobalAddress lowering strategy recently and was wondering if anyone had any ideas, insights, or experience to share. ## Background When lowering global address, which is typically done in FooTargetLowering::LowerGlobalAddress you have the option of folding in the global offset into the global address or els...

...018-April/122810.html) for offloading to FPGA accelerators. ## LLVM commits * GlobalISel now has dedicated extended loads. [r331115](https://reviews.llvm.org/rL331115). * A new AArch64 DAG combine will fold offsets into addresses in the case where all users of the global address are of the form globaladdr + constant. [r330630](https://reviews.llvm.org/rL330630). * The new CFIInserter pass is used to ensure correct dwarf unwind information is emitted in the function epilogue. It is currently x86-only. [r330706](https://reviews.llvm.org/rL330706). * The 'call' pseudoinstruction is now suppor...

..., R12, LR, > D0, D1, D2, D3, D4, D5, D6, D7, CPSR] in { > > def ARM_ATOMIC_CMP_SWAP : ABXI<0b1011, (outs GPR:$dst), (ins > i32imm:$ptr, i32imm:$old, i32imm:$new), > "do_something", > [(set GPR:$dst, > (atomic_cmp_swap_32 globaladdr:$ptr, imm:$old, > imm:$new))]>; > } > > What I want to achieve first is that llc picks this definition when it > finds an occurance of the @atomic.cmp.swap.i32 intrinsic. > > Therefore I wrote a basic .ll file containing only a call to this > function. I then let it run t...

Hello, I am learning to write a new backend for LLVM and have a few simple questions. 1) What are the differences between 'constant' and 'targetconstant', 'globaladdress' and 'targetglobaladdress'? It is not clear from the document when and which should be used. 2) On the processor I am working on, there is a 'move reg, mem_addr' instruction. When I try to match it using the pattern [(set Int32Regs::reg, tglobaladdr::mem_addr)]. the code g...

...et *Subtarget = &TM.getSubtarget<AArch64Subtarget>(); - + Subtarget = &TM.getSubtarget<AArch64Subtarget>(); // SIMD compares set the entire lane's bits to 1 setBooleanVectorContents(ZeroOrNegativeOneBooleanContent); @@ -2050,6 +2050,90 @@ AArch64TargetLowering::LowerGlobalAddressELF(SDValue Op, } } +SDValue +AArch64TargetLowering::LowerGlobalAddressDarwin(SDValue Op, + SelectionDAG &DAG) const { + + EVT PtrVT = getPointerTy(); + SDLoc dl(Op); + const GlobalAddressSDNode *GN = cast<GlobalAddressSDNode>(...

...gt; def GR : RegisterClass<"Bfin", [i32], 32, > [R0, R1, R2, R3, R4, R5, R6, R7, > P0, P1, P2, P3, P4, P5, SP, FP, > I0, I1, I2, I3, M0, M1, M2, M3, > B0, B1, B2, B3, L0, L1, L2, L3]>; > > For instance, I can load an arbitrary 32-bit constant or > globaladdr/externalsym into any register: > > def LOAD32imm: Pseudo<(outs GR:$dst), (ins i32imm:$src), > "$dst.H = HI($src); $dst.L = LO($src);", > [(set GR:$dst, imm:$src)]>; > > I think I am stretching the code generator beyond its...

...} >> > > Since i64imm is an immediate, the constraint "$dst = $addr" doesn't make > sense. The constraint is there to tie the input virtual register to the > output virtual register, so that they will both be assigned the same > physical register. > > > GlobalAddresses get lowered to RelAddr nodes in our ISelLowering code. >> Now I just need to be able to expand this in our overridden >> expandPostRAPseudo function, however, I'm a bit worried that expansion >> happens too late (after things should already be MI's, it seems). So >...