search for: iselpattern

...tst. The simple > isel used to produce ftst for compare against zero. If you do some > benchmarking and find that one is noticably faster than the other, we > should switch them both to use the same code sequence. It's generating _both_ the SAHF and the fucomi -- look at the code ISelPattern generates: 17160443 call HueVMReadCommands_LLVMReadVoxel (19BB229h) 17160448 fsub dword ptr ds:[161D6280h] 1716044E fabs 17160450 fst qword ptr [esp+14h] 17160454 ftst 17160456 fstp st(0) 17160458 fnstsw ax 1716045A sahf 1716045B fldz 1716045D fchs 17160...

...( Right, but once the MI are RAed, you want to be able to do a post-pass scheduling also. So you need to be able to take a MBB and produce a DAG. A scheduler obviously wouldn't care how it came about having a DAG. And it is easier to do the lift from a MBB to a DAG than to change the entire ISelPattern process at the moment. Baby steps. Andrew

...se: http://llvm.cs.uiuc.edu/docs/WritingAnLLVMBackend.html http://llvm.cs.uiuc.edu/docs/TableGenFundamentals.html If you're unsure of how things are implemented, take a look at how similar things are done in X86, PowerPC, Alpha or IA64, they all have SelectionDAG-based instruction selectors (*ISelPattern.cpp). If that doesn't clear things up, ask on the list or IRC channel. -- Misha Brukman :: http://misha.brukman.net :: http://llvm.cs.uiuc.edu

i'd like to know if there is any plan or existing work to add a Aho's trig language like code generator generator? "...If you are starting a new port, we recommend that you write the instruction selector using the SelectionDAG infrastructure." any other things i should know before i write one? thank you.

...ure is mean to support exactly this (perform Tree or DAG pattern matching on the optimized DAG instead of on the LLVM code). This is described here: http://llvm.cs.uiuc.edu/docs/CodeGenerator.html Currently, we use simple greedy bottom-up matchers that are manually written in the <target>ISelPattern.cpp file. The plan is to extend this by allowing targets to write the DAG pattern for each instruction in the .td files, then build use an optimal code generator generator to emit the matching code. This processes of increased automation has been happening slowly over the years, but we've...

http://portal.acm.org/citation.cfm?id=75700 On 4/25/05, Chris Lattner <sabre at nondot.org> wrote: > On Sun, 24 Apr 2005, Tzu-Chien Chiu wrote: > > i'd like to know if there is any plan or existing work to add a Aho's > > trig language like code generator generator? > > Trig is a code generator generator? Is there any documentation for it > available

...his (perform Tree or DAG pattern matching on > the optimized DAG instead of on the LLVM code). > > This is described here: > http://llvm.cs.uiuc.edu/docs/CodeGenerator.html > > Currently, we use simple greedy bottom-up matchers that are manually > written in the <target>ISelPattern.cpp file. The plan is to extend this > by allowing targets to write the DAG pattern for each instruction in the > .td files, then build use an optimal code generator generator to emit the > matching code. > > This processes of increased automation has been happening slowly over the...

...t 0, int 1) store float 0.000000e+000, float* getelementptr ([4 x float]* cast (<4 x float>* %_ARGB56 to [4 x float]*), int 0, int 2) store float 0.000000e+000, float* getelementptr ([4 x float]* cast (<4 x float>* %_ARGB56 to [4 x float]*), int 0, int 3) ret void } Generated with ISelPattern: 17160410 sub esp,1Ch 17160413 mov dword ptr ds:[161D6240h],0 1716041D mov dword ptr ds:[161D6244h],0 17160427 mov dword ptr ds:[161D6248h],0 17160431 mov dword ptr ds:[161D624Ch],0 1716043B mov eax,76E4560h 17160440 mov dword ptr [esp...

...attern matching on >> the optimized DAG instead of on the LLVM code). >> >> This is described here: >> http://llvm.cs.uiuc.edu/docs/CodeGenerator.html >> >> Currently, we use simple greedy bottom-up matchers that are manually >> written in the <target>ISelPattern.cpp file. The plan is to extend this >> by allowing targets to write the DAG pattern for each instruction in the >> .td files, then build use an optimal code generator generator to emit the >> matching code. >> >> This processes of increased automation has been happen...

...e optimized DAG instead of on the LLVM code). > >> > >> This is described here: > >> http://llvm.cs.uiuc.edu/docs/CodeGenerator.html > >> > >> Currently, we use simple greedy bottom-up matchers that are manually > >> written in the <target>ISelPattern.cpp file. The plan is to extend this > >> by allowing targets to write the DAG pattern for each instruction in the > >> .td files, then build use an optimal code generator generator to emit the > >> matching code. > >> > >> This processes of increased a...

On Fri, 18 Mar 2005, Duraid Madina wrote: >>> - No instruction scheduling/bundling of any sort >> >> So this one needs to be coordinated. Next week, I might see about >> adding MachineInstruction support to the SelectionDAG so you can load up >> a DAG post-ISel and then spit it back out scheduled. > > That would be much appreciated, particularly if it

On Wed, 16 Mar 2005, Morten Ofstad wrote: > Hello, > > I didn't get any reply to my previous mail about adding floating point > intrinsics to the X86 pattern instruction selector... And I could really need > some help. Sorry about that, it slipped through the cracks. :( > Anyway, I think my confusion was caused partly by an already > existing bug in the instruction

Hello, I didn't get any reply to my previous mail about adding floating point intrinsics to the X86 pattern instruction selector... And I could really need some help. Anyway, I think my confusion was caused partly by an already existing bug in the instruction selection for floating point compares. The case which emits code for the special case of comparing against constant 0.0 does not

Andrew Lenharth wrote: > On Fri, 2005-03-18 at 05:04 +0900, Duraid Madina wrote: >> - No varargs > > What are your issues here? Or are they simply at the "not implemented > so I don't know" stage? The two bugs I mentioned (no varargs, no alloca) are pretty much two sides of the same coin: I'm ignoring the IA64 stack frame layout (for no good reason), so

Hello, I am trying to make the FP intrinsics (abs, sin, cos, sqrt) I've added work with the X86ISelPattern, but I'm having some difficulties understanding what needs to be done. I assume I have to add new nodetypes for the FP instructions to SelectionDAGNodes.h, and make nodes for these in SelectionDAGLowering::visitCall when I find the intrinsic... The part I don't quite understand is what...