similar to: bind blocking rsync

On Thu, 13 Dec 2018 at 21:41, Friedman, Eli <efriedma at codeaurora.org> wrote: > > On 12/13/2018 6:25 AM, Alex Bradbury wrote: > > There's also likely to be cases where you want to calculate the demanded bits > > in order to determine if e.g. a W-suffixed instruction can be selected for > > `(somoeop (zexti32 GPR:$rs1), (zexti32 GPR:$rs2))`. This is easy to match

I've been looking to see if there's a way to get the instruction below (SMAC) emitted from a higher-level construct, but I'm starting to think this is unrealistic. To do so, I'd have to tie-in two other instructions: Firstly, clearing the ASR18 and Y register somewhere near the start of the method, then copying out the value of these registers somewhere near the end of the method,

I'm trying to define a multiply-accumulate instruction for the LEON processor, a Subtarget of the Sparc target. The documentation for the processor is as follows: === To accelerate DSP algorithms, two multiply&accumulate instructions are implemented: UMAC and SMAC. The UMAC performs an unsigned 16-bit multiply, producing a 32-bit result, and adds the result to a 40-bit accumulator made

As previously discussed in an RFC <http://lists.llvm.org/pipermail/llvm-dev/2018-October/126690.html>, the RISC-V backend has i64 as the only legal integer type for the RV64 target. Thanks to variable-sized register class support, this means there is no need for duplication of either patterns or instruction definitions for RV32 and RV64. It's worth noting that RV64I is a different base

Hi, I've implemented parallelization in one of my packages using the 'parallel' package -- many thanks for providing it! In my package I'm importing 'parallel' and so added it to the DESCRIPTION file's 'Import:' tag and also added a 'importFrom("parallel", ...)' statement in the NAMESPACE file. Parallelization works nicely, but my package

My data looks like this: > data name G_hat_0_0 G_hat_1_0 G_hat_2_0 G_0 G_hat_0_1 G_hat_1_1 G_hat_2_1 G_1 1 rs0 0.488000 0.448625 0.063375 1 0.480875 0.454500 0.064625 1 2 rs1 0.002375 0.955375 0.042250 1 0.000000 0.062875 0.937125 2 3 rs2 0.050375 0.835875 0.113750 1 0.877250 0.115875 0.006875 0 4 rs3 0.000000 0.074750 0.925250 2 0.897750 0.102000

Dumb question about llvm-tblgen for "XyzGenInstrInfo.inc" If I have a pattern in my dot-td-file like this [(set i32:$dst (add i32:$rs1, i32:$rs2))] The question is where does the token "i32" come from, I don't see any definitions for i1, i8, i16, i32, ... in include/llvm/Target/*.td while I do see definitions for tokens like

in llvm-3.6.2.src 1. when I put this around one of my instruction definitions in my target "InstrInfo.td" file, let TwoOperandAliasConstraint = "$dst = $rs1" in { } I do not see any TIED_TO in the generated GenInstrInfo.inc file for the OperandInfo used by the instruction, the question is what am I doing wrong ? 2. I've noticed that TwoOperandAliasConstraint

Hi Peter, I would recommend looking into the implementation of the matcher if you want to add more builtin types: utils/TableGen//DAGISelMatcherGen.cpp That being said, you can define your own types without having to go through that hassle. E.g., from AArch64 def simm9 : Operand<i64>, ImmLeaf<i64, [{ return Imm >= -256 && Imm < 256; }]> { let ParserMatchClass =

Hi Im trying to add RISC V Store Instruction for an Experiment on my Target. The thing is, llvm Store Format gets Register and Pointer Type Operand. beside this, RISC-V Store Instruction takes source Register, Base Register and offset immediate type. So this takes 3 leafs. In this case, should I make new SelectionDAG Node in this case? or use BuildMI Instruction to add new Register? P.S.

Quentin, My real problem is that my target has separate address and data registers. The way I’d like to try getting better reg-alloc than I am now is to bring out the difference as Early as possible, so I have added p16, p32, p64 to the enum in “MachineValueType.h” And I have called addRegisterClass(MVT::p32, &XyzAddrRegsRegClass); And I have an override for virtual

Greetings, while attempting to TableGen-ify the Sparc code generator, I've hit a bit of a snag. Sparc has a few well-defined instruction formats. For example, format 3 operation 3 (F3_3) is as follows: [op][rd][op3][rs1][opf][rs2] op = 3 rd = destination register op3 = opcode rs1 = source register 1 opf = opcode (floating-point) rs2 = source register 2 So far so good. However, some

Hello everyone, I wanted to attach a node without affecting the present nodes in any way. I tried to use MVT::Glue for that but I think I'm missing something as I could not achieve the below state. LUI LUI | | ADDI ----GLUE---- ADDI | store I've few question about this and Glue node in general, I'll be happy to get some help on

Hi, I'm not sure. But in your lowered DAG the chain nodes are the first operands for you custom nodes, however for the other nodes the chain is the last operand. I seem to remember that during targetlowering the chain is the first operand and then it seems to switch over after ISelDAG, this confused me and may have something to do with the issue that you are seeing. I really don't

I don’t quite follow why you are doing something like this. What is the advantage of this instead of just attaching the AddrRegs regsister class as the register class for your instruction? So that you would have an ADD instruction like %AddrRegOut = ADD %AddrRegIn1, %AddrRegIn2 What kind of problematic regalloc are you trying to avoid with introducing a new backend data type? Marcello > On

The i32 class is defined in include/llvm/CodeGen/ValueTypes.td along with a class for every type in MachineValueTypes.h On Wed, May 25, 2016 at 8:12 PM, Marcello Maggioni via llvm-dev < llvm-dev at lists.llvm.org> wrote: > I don’t quite follow why you are doing something like this. > > What is the advantage of this instead of just attaching the AddrRegs > regsister class as the

Hi, ABCRegister.td : def SGPR32 : RegisterClass<"ABC", [i32], 16, (add S0, S1, S2, S3, S4, S5, S6, S7, S8, S9, S10, S11, S12, S13, S14, S15 )>; def SFGPR32 : RegisterClass<"ABC", [f32], 16, (add S0, S1, S2, S3, S4, S5, S6, S7, S8, S9, S10, S11, S12, S13, S14, S15 )>; ===== Instruction selection ends: ... t8: i32 = ADDrr t37, t32

Dear Alex, all, I was looking for fcvt.d.{w,l}{,u} in RISCVInstrInfoD and I'm not sure to understand the current definitions: 138 def FCVT_D_W : FPUnaryOp_r<0b1101001, 0b000, FPR64, GPR, "fcvt.d.w"> { 139 let rs2 = 0b00000; 140 } 141 142 def FCVT_D_WU : FPUnaryOp_r<0b1101001, 0b000, FPR64, GPR, "fcvt.d.wu"> { 143 let rs2 =

Craig, Ahha, thanks. Even with that info I had to resort to “find-grep” to figure out how it gets #included, Being indirectly included from “include/llvm/IR/Intrinsics.td” isn’t exactly obvious :=(( Would it be possible move the #include into “Target.td” ? Also, in “ValueTypes.td” there is a comment about needing to keep it coordinated With “MahineValueType.h”, but there is no such

You are welcome. I changed the pattern, the same old error pop up again, crash in the same place. Type set is empty for each HW mode: possible type contradiction in the pattern below (use -print-records with llvm-tblgen to see all expanded records). vtInt: &nbsp; (vt:{ *:[Other] }) UNREACHABLE executed at /home/nancy/work/rpp_clang/llvm/utils/TableGen/CodeGenDAGPatterns.cpp:824!