similar to: [LLVMdev] Use two ComplexPatterns (possible bug of TableGen?)

I'm trying to write a store pattern that accepts both i32 and f32, however, when tablegen generates the code, it only generates the code for i32 only. def ADDR : ComplexPattern<i32, 2, "SelectADDR", [], []>; def MEM : Operand<i32> { let PrintMethod = "printMemOperand"; let MIOperandInfo = (ops GPR, GPR); } def global_st :

On Sep 23, 2008, at 10:44 AM, Villmow, Micah wrote: > I’m trying to write a store pattern that accepts both i32 and f32, > however, when tablegen generates the code, it only generates the > code for i32 only. > > def ADDR : ComplexPattern<i32, 2, "SelectADDR", [], []>; > def MEM : Operand<i32> { > let PrintMethod = "printMemOperand";

Dear All: I run a logistic regression (using lrm in the Design package), and after that, I use the command "summary" to get the marginal effects of each variable. But one strange thing happens on my binary dependent variable: The marginal effect of it jumping from 0 to 1 is 1.77. I believe the marginal effect of binary variable x1 has interpretation should be P(Y=1|x1=1,

On Feb 13, 2009, at 9:47 AM, Alex wrote: > It seems to me that LLVM sub-register is not for the following > hardware architecture. > > All instructions of a hardware are vector instructions. All > registers contains > 4 32-bit FP sub-registers. They are called r0.x, r0.y, r0.z, r0.w. > > Most instructions write more than one elements in this way: > > mul

It seems to me that LLVM sub-register is not for the following hardware architecture. All instructions of a hardware are vector instructions. All registers contains 4 32-bit FP sub-registers. They are called r0.x, r0.y, r0.z, r0.w. Most instructions write more than one elements in this way: mul r0.xyw, r1, r2 add r0.z, r3, r4 sub r5, r0, r1 Notice that the four elements of r0 are written

Alex schrieb: > It seems that it's not allowed to two same 'ComplexPattern's in a 'def', > because TableGen generate the same variable names for the two ComplexPatterns. > If I understand the source code of TableGen correctly, it's not designed to > use more than one ComplexPattern instance (no matter they are the same or not). I've run into this too, the

On Jan 15, 2009, at 12:50 AM, Brandner wrote: > On Wednesday 14 January 2009 18:59:03 Brandner Florian wrote: >> I have a patch against llvm 2.4 that fixes this issue, but did not >> have >> the time to post the patch here. I'll do so by tomorrow. > > here is the patch, still against llvm 2.4. I had a short look on > trunk, but it > seems that there are

On Wednesday 14 January 2009 18:59:03 Brandner Florian wrote: > I have a patch against llvm 2.4 that fixes this issue, but did not have > the time to post the patch here. I'll do so by tomorrow. here is the patch, still against llvm 2.4. I had a short look on trunk, but it seems that there are several conflicts. Maybe a tablgen expert should have a look at this - I also do not know if

Hi Dan, thank you for applying the patch. > However, I didn't apply this part: > > - if (InstPatNode && InstPatNode->getOperator()->getName() == > "set") { > + if (InstPatNode && !InstPatNode->isLeaf() && > + InstPatNode->getOperator()->getName() == "set") { > > because I'm unsure what

Currently tablegen emits a rather surprising match code for the following case: Suppose we have a pattern that uses a ComplexPattern to match an operand. This pattern then appears as a child pattern in a different pattern. Pattern 1: (N1 ComplexPattern:OP) Pattern 0: (N0 (N1 ComplexPattern:OP)) The match code for ComplexPattern is passed in N1 in Pattern 1 and N0 in Pattern 0. This means

On Dec 30, 2007, at 9:04 PM, Christopher Lamb wrote: > Currently tablegen emits a rather surprising match code for the > following case: > > Suppose we have a pattern that uses a ComplexPattern to match an > operand. This pattern then appears as a child pattern in a > different pattern. > Pattern 1: (N1 ComplexPattern:OP) > Pattern 0: (N0 (N1 ComplexPattern:OP)) >

On Jan 1, 2008, at 9:29 PM, Evan Cheng wrote: > > On Dec 30, 2007, at 9:04 PM, Christopher Lamb wrote: > >> Currently tablegen emits a rather surprising match code for the >> following case: >> >> Suppose we have a pattern that uses a ComplexPattern to match an >> operand. This pattern then appears as a child pattern in a >> different pattern.

Hi, I was wondering if someone could explain precisely what the ComplexPattern tablegen class does? Here's the first line of the definition (from TargetSelectionDAG.td) for reference: class ComplexPattern<ValueType ty, int numops, string fn, list<SDNode> roots = [], list<SDNodeProperty> props = [],

Hi All I'm having nightmares with FrameIndexes during my backend development :( I have ComplexPatterns defined for my two addressing modes (RR and RI). Most of the time, FrameIndex operands appear to be on load/store nodes, in which case everything works fine as my custom addressing modes matchers work fine. Unfortunately, I now have an add node which has a FrameIndex operand (this results

Hi, I've come across a problem while working on an LLVM backend for a new target architecture. This architecture has two single-ported register files. Each instruction can only read one operand from each register file, but can write to either. I tried implementing it naïvely in TableGen with two definitions per instruction, so I had: def AllRegs : RegisterClass< ... (add interleave

Hi All, I've more or less finished updating the examples to the DAG style we were talking about. Hopefully I haven't forgotten anything, there was a lot to keep track of :-). Overall, I think there's a couple places where things get a a little awkward (mainly debug info) but things generally look good to me. A Simple Example def : GICombineRule<(defs reg:$D, reg:$S),

> On Nov 29, 2018, at 01:57, Nicolai Hähnle <nhaehnle at gmail.com> wrote: > > Hi Daniel, > > > On 27.11.18 18:59, Daniel Sanders wrote: >> I've more or less finished updating the examples to the DAG style we were talking about. Hopefully I haven't forgotten anything, there was a lot to keep track of :-). Overall, I think there's a couple places where

Hi all, I started to write an LLVM backend for custom CPU. I created XXXInstrInfo but there are some problems. I searched for it but I couldn't find anything. Can anyone help me? include "XXXInstrFormats.td" def simm16 : Operand<i32> { let DecoderMethod = "DecodeSimm16"; } def mem : Operand<i32> { let PrintMethod = "printMemOperand"; let

Hi All, I've been working on the GlobalISel combiner recently and I'd like to share the plan for how Combine Rules will be defined in GlobalISel and solicit feedback on it. This email ended up rather long so: TL;DR: We're planning to define GlobalISel Combine Rules using MIR syntax with a few bits glued on to interface with the algorithm and escape into C++ when we need to.

Thanks Nicolai! > On Nov 9, 2018, at 02:55, Nicolai Hähnle <nhaehnle at gmail.com> wrote: > > Hi Daniel, > > Lots of good stuff in there! I especially like the design for specifying out-of-line predicates. I have a couple of small comments and one major one below. > > > On 09.11.18 02:42, Daniel Sanders via llvm-dev wrote: >> _Passing arbitrary data from