search for: xxxgendagisel

Hi, I'd like to understand the order in which patterns are searched during ISEL. In the example below, indices are searched in ascending order from 808 to 3305, then it goes back to 3259 and eventually it matches the wrong instruction. Why did go back from 3305 to 3259? In my XXXGenDAGISel.inc, I can see that the correct instruction is at index 3420 but it never got there. ISEL: Starting pattern match Skipped scope entry (due to false predicate) at index 3, continuing at 808 Skipped scope entry (due to false predicate) at index 809, continuing at 865 Skipped scope entry (due t...

...previous one] /.../llvm-build/lib/Target/ARM/ARMGenDAGISel.inc:191: error: syntax error before `{' token ... [lots of other errors generated by the previous one] ... The NOINLINE-macro after each method's argument list and right before the "{" in the various lib/Target/XXX/XXXGenDAGISel.inc-files seems to be the culprit, e.g. in llvm-build/lib/Target/ARM/ARMGenDAGISel.inc (line 145): void Emit_0(SDOperand &Result, SDOperand &N, unsigned Opc0, SDOperand &Chain, SDOperand &N1, bool HasInFlag) NOINLINE { ... If I remove all NOINLINE appearances, everything co...

In an attempt to add vector registers to my target, I ran into a problem. LLVM started to complain about not being able to infer types from the provided DAG patterns for several classes of instructions. After a discussion on the llvm-dev mailing list and IRC channel the recommendation was to make DAG patterns for these classes of instructions more specific. Which is what was done. However after

On 10/30/2012 04:52 PM, Tim Northover wrote: > Hi Heikki, > >> just using [(set V2I32Regs:$result, (sextloadv2i8 ADDRrr:$address))] >> >> gives me error that extloav2i8 is not defined. > > I don't have a target to test this on, but looking at > include/llvm/Target/TargetSelectionDAG.td, there is an "sextloadvi8" > PatFrag, at least. I'd suggest

...the next step is probably to delve into what the DAG matcher is doing behind the scenes. If you give llc the option "-debug" it should tell you what patterns it's tried to match against the fadd and where they failed. If you cross-reference this with the table in build/lib/Target/XXX/XXXGenDAGISel.inc you should be able to work out where things are going wrong. (There are comments giving what each original pattern was *below* the check that'll fail in each case). > As we are working on half float fp16 support in LLVM are there any plans to > support it on the main trunk ? As I so...

...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 > before the "{" in the various lib/Target/XXX/XXXGenDAGISel.inc- > files seems to be the culprit, e.g. in llvm-build/lib/Target/ARM/ > ARMGenDAGISel.inc (line 145): Is this patch incorporated on the 1.8 branch? http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of- Mon-20060731/036455.html g.

...senciasetflag > does not have any values that can be assigned to a > register, so it's probably this part that causes the pattern to fail. > Would you mind showing how to make Esenciasetflag to actually set a flag? I can't figure out the syntax. > > > Tablegen creates a xxxGenDAGISel.inc file in your target's build > directory. The "index" numbers that the debugging info shows correspond to > the numbers in that file. Here's an example from HexagonGenDAGISel.inc: > > /*28*/ OPC_Scope, 88|128,3/*472*/, /*->503*/ // 3 children in &gt...

hi all, i am trying to implement native support for fp16 in llvm-3.1 i have already used the opencl patch for clang so the IR that is generated is correct. i tried to add some code so the the fp16 type is handled correctly but no luck. We have a target that has native fp16 units and tried to run a simple program int main () { __fp16 a,b,c,d; a= 1.1; b=2.2; c=3.3;