similar to: [LLVMdev] cygwin build broken (X86ISelDAGToDAG.cpp: ‘LOCK_OR8mi’ is not a member of ‘llvm::X86’)

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’

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 >>

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/18/2011 1:47 AM, Eric Christopher wrote: > 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:

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, -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

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 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.

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 it knew isel would turn into (e.g.) unpck operations. Now > instead of

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

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

All, As I've done more integrating of AVX work upstream and more tuning here, I've run across several things which are clunky in the current isel design. A couple examples I can remember offhand: 1. We have special target-specific operators for certain shuffles in X86, such as X86unpckl. I don't completely understand why but Bruno indicated it was to address inefficiecies.

On Mar 16, 2011, at 1:44 PM, David Greene wrote: > All, > > As I've done more integrating of AVX work upstream and more tuning here, > I've run across several things which are clunky in the current isel > design. A couple examples I can remember offhand: > > 1. We have special target-specific operators for certain shuffles in X86, > such as X86unpckl. I

(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

Hi Ankur, > The flags "-view-sched-dags".. described in the doc doesn't seem to work. ( > "llc -help" doesn't list it ). as far as I remember, displaying DAGs during compilation is only enabled in "debug builds" [1] of LLVM. You probably have to re-configure and re-compile LLVM to enable this feature. Best regards, Christoph [1]

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

I am trying to understand the SelectionDAG construction from LLVM IR. I have gone through the doc "The LLVM Target-Independent Code Generator" on LLVM site. This gives a great initial overview. However I am unable to catch the actual control flow for the llvm->selectionDag conversion. The flags "-view-sched-dags".. described in the doc doesn't seem to work. ( "llc

Hi Tyler, > -Does anyone know where a backend-specific optimization can be added to replace > an instruction with code containing control flow? I think the backend lowering of atomic intrinsics generates control flow (loops), so that may give you a clue. Ciao, Duncan.

On Mar 12, 2010, at 8:10 AM, David Greene wrote: > On Friday 12 March 2010 08:13:05 Kalle Raiskila wrote: >> David Greene wrote: >>> Here's a rework using PassManager as Chris suggested. Comments? >> >> Tried this second patch with the svn version 97812 (the one the patch is >> made against), but it doesn't compile: >>

Hi Bruce, Thanks for you reply. I check the *.td files under the lib/Target/X86 folder, but have not got interesting findings. It requires some knowledge of LLVM backend to fully understand the *.td files. I will get some background and keep searching. Of course I appreciate if anyone with such experience can point the concrete locations. Regards, Hu Hong On 17 October 2016 at 22:20, Bruce