similar to: [LLVMdev] 1728 unused functions

On May 14, 2011, at 3:08 AM, Eric Niebler wrote: > Just a heads up that the llvm build appears to be broken on cygwin. I > haven't investigated, but here's the failures: > > llvm[3]: Compiling X86ISelDAGToDAG.cpp for Release+Asserts build > /home/Eric/boost/consulting/svn/llvm/lib/Target/X86/X86ISelDAGToDAG.cpp:1487: > error: ‘LOCK_OR8mi’ is not a member of ‘llvm::X86’

Just a heads up that the llvm build appears to be broken on cygwin. I haven't investigated, but here's the failures: llvm[3]: Compiling X86ISelDAGToDAG.cpp for Release+Asserts build /home/Eric/boost/consulting/svn/llvm/lib/Target/X86/X86ISelDAGToDAG.cpp:1487: error: ‘LOCK_OR8mi’ is not a member of ‘llvm::X86’ /home/Eric/boost/consulting/svn/llvm/lib/Target/X86/X86ISelDAGToDAG.cpp:1488:

On May 17, 2011, at 2:50 AM, Eric Niebler wrote: > On 5/17/2011 2:58 AM, Eric Christopher wrote: >> On May 14, 2011, at 3:08 AM, Eric Niebler wrote: >> >>> Just a heads up that the llvm build appears to be broken on cygwin. I >>> haven't investigated, but here's the failures: >>> >>> llvm[3]: Compiling X86ISelDAGToDAG.cpp for

On 5/17/2011 2:58 AM, Eric Christopher wrote: > On May 14, 2011, at 3:08 AM, Eric Niebler wrote: > >> Just a heads up that the llvm build appears to be broken on cygwin. I >> haven't investigated, but here's the failures: >> >> llvm[3]: Compiling X86ISelDAGToDAG.cpp for Release+Asserts build >>

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

(resending with smaller attachement) Segfault in EE->getPointerToFunction. I think it's blown the stack, gdb reports a never ending backtrace (below). I generate llvm assembly and parse/verify OK. Attached is the assembly. It is the smallest example generated that causes the segfault. If this EE uses a recursive function (??), it seems an inherent limitation in how big llvm functions

Segfault in EE->getPointerToFunction. I think it's blown the stack, gdb reports a never ending backtrace (below). I generate llvm assembly and parse/verify OK. Attached is the assembly. It is the smallest example generated that causes the segfault. If this EE uses a recursive function (??), it seems an inherent limitation in how big llvm functions can be. Simon. gdb backtrace: #0

Hi, after perusing through llc -debug output and stepping through the ARMGenDAGIsel.inc in the debugger, I would greatly like some help in tracking down a failing match to a pattern I specified: First, here is a snippet of a successful match (done in ARM mode) ISEL: Starting pattern match on root node: 0x1e7adf0: i32,ch = load 0x1e4c030, 0x1e78210, 0x1e78310<LD4[ConstantPool]> [ID=10]

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

Hi, -Does anyone know where a backend-specific optimization can be added to replace an instruction with code containing control flow? I'm interested in adding an optimization for the DIV instruction (x86-atom) which replace the IDIV/DIV with code containing control flow to select between the intended IDIV/DIV and an 8-bit DIV with movzx, as described in the Intel Atom Optimization Guide. My

Hi Simon, You're probably right. LLVM's instruction selector is recursive so it can run out of stack space. Select_store used to have enormous stack frame (thanks to some gcc issues), we had to do all kinds of tricks to get it under control. I just took a look at it, it's around 0.7k. It used to be around 20k on x86 Mac OS X. It's also possible that it has gotten into a

Hi Anton & Duncan, When I try to compile on Darwin now, I get this: $ /Volumes/Gir/devel/llvm/llvm-gcc-4.0.obj/gcc/xgcc <options> -o eh_alloc.o Assertion failed: (false && "Couldn't find the register class"), function getPhysicalRegisterRegClass, file /Volumes/Gir/devel/llvm/ llvm.src/lib/CodeGen/SelectionDAG/ScheduleDAG.cpp, line 269.

On Wed, Jun 11, 2008 at 11:49 AM, Gordon Henriksen <gordonhenriksen at mac.com> wrote: > Could you please update to r52213 or later in svn and check whether > this error is resolved with your gcc? Latest trunk fixes that error. Next problem :) llvm[3]: Building ARM.td register information header with tblgen llvm[3]: Building ARM.td register names with tblgen llvm[3]: Building ARM.td

On Mar 17, 2011, at 9:32 AM, David A. Greene wrote: > Chris Lattner <clattner at apple.com> writes: >>> 1. We have special target-specific operators for certain shuffles in X86, >>> such as X86unpckl. > >> It also eliminates a lot of fragility. Before doing this, X86 >> legalize would have to be very careful to specifically form shuffles >> that

On Jun 25, 2009, at 4:38 PM, David Goodwin wrote: > Using the Thumb-2 target we see that ORN ( a | ^b) and BIC (a & ^b) > have similar patterns, as we would expect: > > defm t2BIC : T2I_bin_irs<"bic", BinOpFrag<(and node:$LHS, (not node: > $RHS))>>; > defm t2ORN : T2I_bin_irs<"orn", BinOpFrag<(or node:$LHS, (not node: >

On 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

On Jun 25, 2009, at 6:06 PM, Evan Cheng wrote: > > On Jun 25, 2009, at 4:38 PM, David Goodwin wrote: > >> Using the Thumb-2 target we see that ORN ( a | ^b) and BIC (a & ^b) >> have similar patterns, as we would expect: >> >> defm t2BIC : T2I_bin_irs<"bic", BinOpFrag<(and node:$LHS, (not >> node:$RHS))>>; >> defm t2ORN :

On Dec 17, 2009, at 4:08 PM, David Greene wrote: > 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

It would be useful if you can post some example code and what you think the assembly code should look like. On Mar 26, 2009, at 5:41 PM, Robert Schuster wrote: > Hi, > I have reworked my previous example and got something which is > accepted > by tblgen: > > let isCall = 1, > Defs = [R0, R1, R2, R3, R12, LR, > D0, D1, D2, D3, D4, D5, D6, D7, CPSR] in { >

On Aug 9, 2006, at 06:17, Bram Adams wrote: > 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, ...) > > The NOINLINE-macro after each method's argument list and right