Displaying 11 results from an estimated 11 matches for "switchopcod".
Did you mean:
switchopcode
2016 Jun 02
2
BPF backend with vector operations - error "Could not infer all types in, pattern!"
Hello.
I come back to this older thread.
Again, because of i64immSExt32 I receive TableGen error "Could not infer all types
in, pattern!" (exact details written below). So far I'm not able to generate selection
code with TableGen for the ADD_r* instructions, etc:
def i64immSExt32 : PatLeaf<(imm),
[{return
2020 Nov 12
2
Musings on the TableGen -emit-dag-isel backend
...000 ( 0.0%) 0.0156 ( 14.3%) 0.0156 ( 0.0%) 0.0030 ( 0.0%) Write output
162.8182 (100.0%) 0.1092 (100.0%) 162.9274 (100.0%) 162.9173 (100.0%) Total
Emitting the C++ code for most pattern operators is straightforward.
However, three operators are more time-consuming: Matcher::Scope,
SwitchOpcode, and SwitchType. These operators take a list of child patterns,
each of which is emitted as a 1- to 3-byte size followed by the child's
pattern bytes. The size is coded as a variable-length sequence of bytes,
as is every integer in the matcher table. (Just for interest, the average
number of c...
2020 Nov 13
1
Musings on the TableGen -emit-dag-isel backend
Would it make sense for TableGen to generate the outer OPC_SwitchOpcode offset table?
At 11/13/2020 07:53 AM, Nicolai Hähnle wrote:
>That said, if we are seriously thinking about the performance of the byte code, perhaps some of these opcodes should be reconsidered at a higher level anyway.
>
>For example: The overall bytecode always begins with an OPC_Swi...
2020 Nov 13
4
Musings on the TableGen -emit-dag-isel backend
...0.0156 ( 0.0%) 0.0030 ( 0.0%)
> Write output
> 162.8182 (100.0%) 0.1092 (100.0%) 162.9274 (100.0%) 162.9173
> (100.0%) Total
>
> Emitting the C++ code for most pattern operators is straightforward.
> However, three operators are more time-consuming: Matcher::Scope,
> SwitchOpcode, and SwitchType. These operators take a list of child
> patterns, each of which is emitted as a 1- to 3-byte size followed by the
> child's pattern bytes. The size is coded as a variable-length sequence of
> bytes, as is every integer in the matcher table. (Just for interest, the
>...
2016 Jan 15
2
Expanding a PseudoOp and accessing the DAG
On 1/15/2016 2:57 PM, Phil Tomson wrote:
>
>
> I see the following in my SelectCode (in XSTGGenDGISel.inc):
>
>
> /*2235*/ OPC_SwitchOpcode /*2 cases */, 27,
> TARGET_VAL(XSTGISD::ADDR_NORMAL),// ->2266
> /*2239*/ OPC_RecordChild0, // #1 = $addr
> /*2240*/ OPC_MoveChild, 0,
> /*2242*/ OPC_CheckOpcode, TARGET_VAL(ISD::TargetGlobalAddress),
> /*2245*/ OPC_MoveParent,
> /*2246*/...
2020 Nov 13
3
Musings on the TableGen -emit-dag-isel backend
Your suggestion for two passes is indeed my plan if simply using 3-byte sizes is not acceptable. I don't want to duplicate all the logic in a second length-calculating function, so I would just have special logic for the three matching operators with children and use the existing function for the rest, passing a null output stream. Or I could conditionalize all the output on another function
2020 Nov 12
0
Musings on the TableGen -emit-dag-isel backend
...000 ( 0.0%) 0.0156 ( 14.3%) 0.0156 ( 0.0%) 0.0030 ( 0.0%) Write output
162.8182 (100.0%) 0.1092 (100.0%) 162.9274 (100.0%) 162.9173 (100.0%) Total
Emitting the C++ code for most pattern operators is straightforward.
However, three operators are more time-consuming: Matcher::Scope, SwitchOpcode, and SwitchType. These operators take a list of child patterns, each of which is emitted as a 1- to 3-byte size followed by the child's pattern bytes. The size is coded as a variable-length sequence of bytes, as is every integer in the matcher table. (Just for interest, the average number of c...
2014 Mar 08
2
[LLVMdev] Isel DAG documentation?
On 8 March 2014 00:53, Owen Anderson <resistor at mac.com> wrote:
> ISDOpcodes.h contains what documentation there is on the semantics of each
> opcode.
And TargetOpcodes.h for a few of the post-ISel ones (mostly they're in
MachineInstr form, but you'll see them with -view-sched-dags, and
occasionally before).
Tim.
2020 Nov 13
0
Musings on the TableGen -emit-dag-isel backend
...6 ( 14.3%) 0.0156 ( 0.0%) 0.0030 ( 0.0%) Write output
> 162.8182 (100.0%) 0.1092 (100.0%) 162.9274 (100.0%) 162.9173 (100.0%) Total
>
> Emitting the C++ code for most pattern operators is straightforward.
> However, three operators are more time-consuming: Matcher::Scope, SwitchOpcode, and SwitchType. These operators take a list of child patterns, each of which is emitted as a 1- to 3-byte size followed by the child's pattern bytes. The size is coded as a variable-length sequence of bytes, as is every integer in the matcher table. (Just for interest, the average number of c...
2014 Mar 09
2
[LLVMdev] Isel DAG documentation?
...gt; [(set GR32:$rD, globaladdr:$addr)]
> It seems to have somehow managed to create a cycle in the DAG, which is
> of course wrong. But how?
When I write a similar pattern into the ARM .td files and look at
(from the build directory) lib/Target/ARM/ARMGenDAGISel.inc, I see:
/*56478*/ /*SwitchOpcode*/ 13, TARGET_VAL(ISD::GlobalAddress),// ->56494
/*56481*/ OPC_RecordNode, // #0 = $src
/*56482*/ OPC_CheckType, MVT::i32,
/*56484*/ OPC_CheckPatternPredicate, 4, // (!Subtarget->isThumb())
/*56486*/ OPC_MorphNodeTo, TARGET_VAL(ARM::MOVi32imm), 0,
1/*#VTs*/,...
2016 Feb 19
3
Failure to match a DAG after a minor pattern change in a custom Target
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