search for: getoperator

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 it's for. When is a "set" node a leaf? exactl...

...of the patch that rename the CPTmp variables: http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20090112/072209.html http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20090112/072210.html 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 it's for. When is a "set" node a leaf? BTW, the FastISelEmitter sho...

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

Hello, Edd > > llvm[3]: Building ARM.td instruction selector implementation with tblgen > > assertion "getOperator()->isSubClassOf("SDNodeXForm") && "Unknown node > > type!"" failed: file "CodeGenDAGPatterns.cpp", line 949, function > > "ApplyTypeConstraints" Could you please try with gcc 4.x and check, whether this problem exists for you or no...

Hi there, I am a student considering a compiler design based dissertation with llvm. I am having problems building llvm on OpenBSD-current. I hope to make a port of llvm for OpenBSD once I have figured out how to build it. Observe: llvm[3]: Compiling Deserialize.cpp for Release build In file included from /home/edd/llvm/llvm-2.3/include/llvm/Bitcode/BitstreamRead er.h:18, from

...Thu, Jun 12, 2008 at 7:02 PM, Edd Barrett <vext01 at gmail.com> wrote: > gcc4.2 works fine. But it only works fine for svn snapshots. Your most recent release does not build on OpenBSD with gcc-4.2. llvm[3]: Building ARM.td instruction selector implementation with tblgen assertion "getOperator()->isSubClassOf("SDNodeXForm") && "Unknown node type!"" failed: file "CodeGenDAGPatterns.cpp", line 932, function "ApplyTypeConstraints" gmake[3]: *** [/usr/ports/devel/llvm/w-llvm-2.3/llvm-2.3/lib/Target/ARM/Release/ARMGenDAGISel.inc.tmp] Abo...

On Thu, Jun 12, 2008 at 11:41 AM, Anton Korobeynikov <asl at math.spbu.ru> wrote: > Hello, Edd > >> > llvm[3]: Building ARM.td instruction selector implementation with tblgen >> > assertion "getOperator()->isSubClassOf("SDNodeXForm") && "Unknown node >> > type!"" failed: file "CodeGenDAGPatterns.cpp", line 949, function >> > "ApplyTypeConstraints" > Could you please try with gcc 4.x and check, whether this problem exists...

...register info implementation with tblgen llvm[3]: Building ARM.td instruction names with tblgen llvm[3]: Building ARM.td instruction information with tblgen llvm[3]: Building ARM.td assembly writer with tblgen llvm[3]: Building ARM.td instruction selector implementation with tblgen assertion "getOperator()->isSubClassOf("SDNodeXForm") && "Unknown node type!"" failed: file "CodeGenDAGPatterns.cpp", line 949, function "ApplyTypeConstraints" gmake[3]: *** [/tmp/llvm/lib/Target/ARM/Debug/ARMGenDAGISel.inc.tmp] Abort trap (core dumped) gmake[3]: Le...

...Barrett <vext01 at gmail.com> wrote: > > gcc4.2 works fine. > > But it only works fine for svn snapshots. Your most recent release > does not build on OpenBSD with gcc-4.2. > > llvm[3]: Building ARM.td instruction selector implementation with tblgen > assertion "getOperator()->isSubClassOf("SDNodeXForm") && "Unknown node > type!"" failed: file "CodeGenDAGPatterns.cpp", line 932, function > "ApplyTypeConstraints" > gmake[3]: *** [/usr/ports/devel/llvm/w-llvm-2.3/llvm-2.3/lib/Target/ARM/Release/ARMGenDAGIS...

...which aborts about 50% of the time when it feels like it: #1 0x04e521a3 in abort () at /usr/src/lib/libc/stdlib/abort.c:68 #2 0x04df29d7 in __assert2 (file=0x3c0018e1 "CodeGenDAGPatterns.cpp", line=934, func=0x3c0020a6 "ApplyTypeConstraints", failedexpr=0x3c002400 "getOperator()->isSubClassOf(\"SDNodeXForm\") && \"Unknown node type!\"") at /usr/src/lib/libc/gen/assert.c:52 #3 0x1c0d0bcd in llvm::TreePatternNode::ApplyTypeConstraints (this=0x7dfc0700, TP=@0x7c0fb6c0, NotRegisters=false) at CodeGenDAGPatterns.cpp:934 #4 0x1c0cfb6b in l...

On 2008-06-10, at 09:19, Edd Barrett wrote: > I am a student considering a compiler design based dissertation with > llvm. I am having problems building llvm on OpenBSD-current. I hope > to make a port of llvm for OpenBSD once I have figured out how to > build it. Hi Edd, Could you please update to r52213 or later in svn and check whether this error is resolved with your

...patches and gcc 4.2.1 on FreeBSD OK, so I have taken the changes to BitWriter.cpp from svn and that builds that section of code OK for llvm-2.3. The next part I will need help with, as I dont really know where to start: llvm[3]: Building ARM.td instruction information with tblgen assertion "getOperator()->isSubClassOf("SDNodeXForm") && "Unknown node type!"" f ailed: file "CodeGenDAGPatterns.cpp", line 932, function "ApplyTypeConstraints" gmake[3]: *** [/usr/ports/devel/llvm/w-llvm-2.3/llvm-2.3/lib/Target/ARM/Release/ ARMGenInstrInfo.inc.tmp]...

While building an OpenBSD port for LLVM 2.3 I encountered a few issues. The first one is that the system compiler $ gcc -v Reading specs from /usr/lib/gcc-lib/amd64-unknown-openbsd4.3/3.3.5/specs Configured with: Thread model: single gcc version 3.3.5 (propolice) Fails to build TableGen correctly which then crashes while processing the tables for ARM. I fixed this by using gcc 4.2.0 The

..., which is nice again. I link with the .a files, didn't test the new shared library (as Debian's package doesn't built it at all). I have added my comments to ReleaseNotes.html, here is a summary of what I had to change: 1. the iterator cast that was already documented 2. the CallInst getOperator() that was already documented (switched to using CallSite). 3. llvm.mem{cpy,move,set}.* intrinsics take 1 additional param. I used UpgradeIntrinsic* to make them work, since Intrinsic::getDeclaration was changed in an incompatible way too. Are there any other intrinsics that changed? 4. SetCurren...

Good news, everybody! It's that time of year again. We are going to release LLVM 2.8! I'm taking over for Tanya to give her a much needed break. I can only hope to perform as well as she has. This is my first time as release manager, so bear with me if things don't go smoothly. This message is mostly to give you an idea of the schedule we're planning on. It's an aggressive

...ltOperand(Child, InstOps); assert(InstOps.size() > BeforeAddingNumOps && "Didn't add any operands"); // If the operand is an instruction and it produced multiple results, just // take the first one. if (!Child->isLeaf() && Child->getOperator()->isSubClassOf("Instruction")) InstOps.resize(BeforeAddingNumOps+1); ++ChildNo; } ... In other words, if a child produces more than one result SelectionIDAG always takes the first result. Those two lines originate from a patch by Chris Lattner (r99725)...

Hi all, The C++11 (& C11) compare_exchange functions with explicit memory order allow you to specify two sets of semantics, one for when the exchange actually happens and one for when it fails. Unfortunately, at the moment the LLVM IR "cmpxchg" instruction only has one ordering, which means we get sub-optimal codegen. This probably affects all architectures which use