similar to: Tablegen pattern matching question

Hello. I come back to this older thread. Again, because of i64immSExt32 I receive TableGen error "Could not infer all types in, pattern!" (exact details written below). So far I'm not able to generate selection code with TableGen for the ADD_r* instructions, etc: def i64immSExt32 : PatLeaf<(imm), [{return

Hello. I've tried to add some simple arithmetic vector operations to the BPF backend available in the LLVM repo. Because I added in BPFRegisterInfo.td another RegisterClass (taken from the Mips backend): def MSA128W: RegisterClass<"BPF", [v2i64, v2f64], 128, (sequence "W%u", 0, 31)>; in order to support vector for example, ADD

I have a back end which has both scalar and vector registers that alias each other. I'm having a problem generating the ISel from tablegen that appears only when a vector register class is declared to contain integer vectors. At that moment tablegen doesn't seem to be able to infer integer types in patterns that it was able to before, but I'm not clear on why that's the

On Sun, 22 Apr 2007, Christopher Lamb wrote: > I have a back end which has both scalar and vector registers that > alias each other. I'm having a problem generating the ISel from > tablegen that appears only when a vector register class is declared > to contain integer vectors. At that moment tablegen doesn't seem to > be able to infer integer types in patterns that it was

I see. If I put simm16 and immSExt16x in place of uimm16 and immZExt16x respectively, the imm matches but it prints out -32768 (which is invalid for sub16u). We are using uimm16 not match unsigned but for PrintMethod, effectively uimm16 and simm16 are both Operand<i16>. I'm still unclear why simm16 matches and uimm16 does not. Here is the pattern if that helps at all. So just as a

Where does the unsignedSub come from? On 2017-02-15 20:38, Ryan Taylor wrote: > Sorry, it should be: > > defm SUB16u_ : ABD_NonCommutative<"sub16u", unsignedSub, LOADRegs, > GPRRegs, DSTRegs, i16, i16, i16, uimm16, immZExt16x>; > > On Wed, Feb 15, 2017 at 2:37 PM, Ryan Taylor <ryta1203 at gmail.com> > wrote: > >> I see. If I put simm16 and

Hi all, This seems like a dumb question but while setting up a pattern in TD file, I got stuck on trying to get each half of an immediate as the half-sized type (ie. i64 imm -> pair of i32 imm's). Is there an existing way to do it? I've tried the 'EXTRACT_SUBREG' but that seems to error at the end of scheduling. Looking at Target.td, I'm not sure which opcode is meant

On Apr 23, 2007, at 5:06 PM, Chris Lattner wrote: > On Sun, 22 Apr 2007, Christopher Lamb wrote: >> I have a back end which has both scalar and vector registers that >> alias each other. I'm having a problem generating the ISel from >> tablegen that appears only when a vector register class is declared >> to contain integer vectors. At that moment tablegen

Hi Kevin, To get some portion of a constant immediate you can use SDNodeXForms to transform constant SDNodes into other values. For a worked example, in the MIPS backend we use this for constant synthesis by materializing the value into a register: (From lib/Target/MipsInstrInfo.td): // Transformation Function - get the lower 16 bits. def LO16 : SDNodeXForm<imm, [{ return getImm(N,

There can also be other “problems" like this one: http://reviews.llvm.org/D6946 <http://reviews.llvm.org/D6946> - Matthias > On Apr 20, 2015, at 1:44 PM, Tim Northover <t.p.northover at gmail.com> wrote: > >> The DAG combiner also performs the undefined shift -> undef though, so it >> should still be OK > > DAG combiner doesn't really run to

Hi Jonathan, After reading/skimming through the official LLVM backend documents, I actually tried following your steps to write a new backend, but how to write td files still remains unclear. The details are not well explained, though I know most of them can be found in other documents or have already been documented somewhere in the LLVM source code or td files. For a beginner with no

Thanks for your reply. We are propagating sign info to tablegen currently using BinaryWithFlagsSDNode.Flags.hasNoSignedWrap atm. I imagine (I have not looked) they are printed according to instruction in AsmPrinter.cpp (pure speculation). I'm still confused as to why 0x7FFF is ok to match 16 bit int but not 0x8000? Thanks. On Wed, Feb 15, 2017 at 1:44 PM, Manuel Jacob <me at

Digging deeper... 1. Is there a good reason that v2f32 types are excluded from the isFloatingPoint filter? Looks like a bug to me. v2f32 = 22, // 2 x f32 v4f32 = 23, // 4 x f32 <== start ?? v2f64 = 24, // 2 x f64 <== end static inline bool isFloatingPoint(ValueType VT) { return (VT >= f32 && VT <= f128) || (VT

On Mon, 8 May 2017, Krzysztof Parzyszek via llvm-dev wrote: > You can create the differentiation between objects in the data memory and in > the program memory in LowerGlobalAddress (e.g. you can create different ISD > opcodes that generate these addresses) and then use those to select > corresponding instructions. Right, which is how I also understand Zhai Xiang's suggestion

I want to install Ruby 1.8.7 and Rails 2.8.3,i am using ubuntu 11. Thank you -- Posted via http://www.ruby-forum.com/. -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To unsubscribe from this group, send email to

Hi, If we add multiple loop passes to the pass manager in PassManagerBuilder.cpp consecutively without any func/module pass in between, I used to think they would belong to the same loop pass manager. But it does not seem to be the case. For example for this code snippet PM.add(createIndVarSimplifyPass()); // Canonicalize indvars MPM.add(createLoopIdiomPass()); //

Hello, I am working on a AVR backend and have a version up and running that will convert LLVM IR code to assembly code for my target. I have written a bunch of instructions from the AVR Instruction Set in AVRInstrInfo.td and not much else. In a simple test case I am attempting to compile (if that is the word you are supposed to use for this operation) test.ll: define i8 @foo(i8 %a, i8 %b) {

I think this has to do with how the pass manager is populated when we give -O3 vs when we give particular pass names. Some passes have multiple createXYZPass() methods that accept arguments too. These methods call non-default pass constructors, which in turn cause the passes to behave in a different manner. eg: Pass *llvm::createLICMPass() { return new LegacyLICMPass(); } Pass

Hello, According to my understanding, it seems that the result of realloc will not technically alias the original pointer. When the realloc is done in-place the reference <http://en.cppreference.com/w/c/memory/realloc> says: "The original pointer ptr is invalidated and any access to it is undefined behavior (even if reallocation was in-place)." Additionally from the C11 standard

Hi, My understanding of a "dead" register is a def that is never used. However, when I dump the MI after reg alloc on a simple program I see the following sequence: ADJCALLSTACKDOWN64 0, 0, 0, *implicit-def dead %rsp*, implicit-def dead %eflags, implicit-def dead %ssp, implicit %rsp, implicit %ssp CALL64pcrel32 @foo, <regmask %bh %bl %bp %bpl %bx %ebp %ebx %rbp %rbx %r12 %r13 %r14