similar to: [LLVMdev] [Help Needed] tblgen code get a compile error

I've run into a situation in isel where it seems like the selector is generating a cycle in the DAG. I have something like this: 0x215f140: v2f64 = llvm.x86.sse2.min.sd 0x215efd0, 0x21606d0, 0x215eb80 [0] 0x215efd0: i64 = Constant <647> [0] 0x21606d0: v2f64 = scalar_to_vector 0x213b8f0 [0] 0x213b8f0: f64,ch = load 0x213b780, 0x213aa90, 0x213b610 <0x2113690:0> alignment=8

On Friday 03 October 2008 12:06, Dan Gohman wrote: > On Fri, October 3, 2008 9:10 am, David Greene wrote: > > On Thursday 02 October 2008 19:32, Dan Gohman wrote: > >> Looking at your dump() output above, it looks like the pre-selection > >> loads have multiple uses, so even though you've managed to match a > >> larger pattern that incorporates them, they

On Feb 26, 2010, at 2:07 PM, David Greene wrote: > On Friday 26 February 2010 10:34:41 David Greene wrote: >> On Friday 26 February 2010 09:55:32 David Greene wrote: >>> In the continuing quest to try to track down problems we're seeing >>> in >>> SelectionDAG, I added the following assert >>> toSelectionDAG::ReplaceAllUsesOfValuesWith: >>

On Oct 7, 2008, at 12:04 PM, David Greene wrote: > On Friday 03 October 2008 12:06, Dan Gohman wrote: >> On Fri, October 3, 2008 9:10 am, David Greene wrote: >>> On Thursday 02 October 2008 19:32, Dan Gohman wrote: >>>> Looking at your dump() output above, it looks like the pre- >>>> selection >>>> loads have multiple uses, so even though

Ok, this is really complicated. I need some TableGen experts to help here. I need a little help doing a final bit of tblgen hacking. I've hacked tblgen to handle patterns like this: let AddedComplexity = 40 in { def : Pat<(vector_shuffle (v2f64 (scalar_to_vector (loadf64 addr:$src1))), (v2f64 (scalar_to_vector (loadf64 addr:$src2))),

On Friday 26 February 2010 10:34:41 David Greene wrote: > On Friday 26 February 2010 09:55:32 David Greene wrote: > > In the continuing quest to try to track down problems we're seeing in > > SelectionDAG, I added the following assert > > toSelectionDAG::ReplaceAllUsesOfValuesWith: > > Here's a patch to add more of these deleted node asserts. They fire > tons

Thanks Dylan, I am working on a backend which has mulhsu instruction that performs multiplication between signed and unsigned number and returns upper 32 bits into result register. I think I also need to write some code probably as you indicated to check signedness of the operands and based on that lower to mulhsu instruction. -Vivek On Mon, Feb 27, 2017 at 11:13 AM, Dylan McKay <me at

On Fri, October 3, 2008 9:10 am, David Greene wrote: > On Thursday 02 October 2008 19:32, Dan Gohman wrote: > >> Looking at your dump() output above, it looks like the pre-selection >> loads have multiple uses, so even though you've managed to match a >> larger pattern that incorporates them, they still need to exist to >> satisfy some other users. > > Yes,

On Thursday 02 October 2008 19:32, Dan Gohman wrote: > Looking at your dump() output above, it looks like the pre-selection > loads have multiple uses, so even though you've managed to match a > larger pattern that incorporates them, they still need to exist to > satisfy some other users. Yes, I looked at that too. It looks like these other uses end up being chains to

On Friday 26 February 2010 19:09:01 Dan Gohman wrote: > I've now looked at your latest patch. In summary, it does expose a > subtle problem. I haven't seen anything that here would lead to > observable misbehavior yet though. Well, I'm definitely observing misbehavior. I know it has something to do with local changes here but I haven't isolated it yet. >

Hello LLVMDevs, I am looking for an example for how to lower LLVM IR to mulsu kind of instruction. I found that AVR back end have such instruction but AVRInstrInfo.td does not define any DAG pattern for which this instruction gets emitted. def MULSURdRr : FMUL2RdRr<1, (outs), (ins GPR8:$lhs, GPR8:$rhs), "mulsu\t$lhs, $rhs", []>, Requires<[SupportsMultiplication]>; Also

Here's an example patch of how dbgs() will be used. Essentially I will replace uses of errs() with dbgs(). I believe this is the correct thing to do because: - With #define NDEBUG, dbgs() == errs() - With debugging and -debug-buffer-size=0 (the default), dbgs() just passes output to errs(). - When -debug-buffer-size>0, you want to buffer ALL output so that you don't get some

On Tuesday 07 October 2008 15:24, Dan Gohman wrote: > It should. SelectNodeTo is a wrapper around MorphNodeTo, and MorphNodeTo > has code to check for and remove nodes that become dead, specifically to > address this case. If that's not working, it's a bug. > > What version of LLVM are you using here? This is code that has changed > substantially over the last few

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

Thanks Ahmed and also Alex for your replies. This is more or less what I was realising, but it is a great confidence booster to know that it is the correct way also. I can replace all of my various 'Select*' specialisations with version that use 'ReplaceNode/SelectCode' and return 'void', but what about the places where I currently call 'Select(N)' directly?

On Mon, 2011-12-05 at 13:18 -0800, Jakob Stoklund Olesen wrote: > On Dec 5, 2011, at 12:56 PM, Hal Finkel wrote: > > > RegScavenger is complaining about use of an undefined register, CTR8, in > > the BCTR8 instruction, in the following instance (this is from the PPC > > backend): > > > > BB#38: derived from LLVM BB %for.end50 > > Predecessors

"Martin J. O'Riordan" <martin.oriordan at movidius.com> writes: > Thanks Ahmed and also Alex for your replies. > > This is more or less what I was realising, but it is a great > confidence booster to know that it is the correct way also. I can > replace all of my various 'Select*' specialisations with version that > use

Hi, Today I downloaded LLVM 1.8 (until yesterday I used 1.7) and I tried to build it (Slackware 10.2 with default GCC 3.3.6). However, the build process fails each time it reaches lib/Target/XXX/XXXISelDAGToDAG.cpp for all backends (XXX=X86, ARM, ...), e.g. like: /.../llvm-build/lib/Target/ARM/ARMGenDAGISel.inc:145: error: syntax error before `{' token ... [lots of other errors

Hi all, I have problem with specifying complex patterns in PPC Isel backend. I would like to fetch few instructions into one like that: def MatchPAT1 : Pat<(or (or (shl GPRC:$rA, (i32 imm:$imm24)), (and (shl GPRC:$rA, (i32 imm:$imm8)), 0xFF0000) ), (or (srl GPRC:$rA, (i32 imm:$imm24)), (and (shl GPRC:$rA, (i32 imm:$imm8)),0xFF00) )), (myinstr GPRC:$rA)>; That pattern

LLVM Weekly - #148, Oct 31st 2016 ================================= If you prefer, you can read a HTML version of this email at <http://llvmweekly.org/issue/148>. Welcome to the one hundred and forty-eighth issue of LLVM Weekly, a weekly newsletter (published every Monday) covering developments in LLVM, Clang, and related projects. LLVM Weekly is brought to you by [Alex