Displaying 9 results from an estimated 9 matches for "opc_movechild".
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
2016 Jan 15
2
Expanding a PseudoOp and accessing the DAG
...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*/ OPC_MoveParent,
> /*2247*/ OPC_CheckPredicate, 5, // Predicate_unindexedload
> /*2249*/ OPC_CheckPredicate, 6, // Predicate_load
&g...
2016 Jan 15
2
Expanding a PseudoOp and accessing the DAG
On 1/15/2016 1:08 PM, Phil Tomson wrote:
>
> Ah, I see, the defm is a multi-class so I needed to change it to:
>
> def: Pat<(load (XSTGADDR_NORMAL tglobaladdr:$addr)),
> (LOADI64_RI tglobaladdr:$addr, 0)>;
> // Match load from a relocatable address to a load with GRP:
> def: Pat<(load (XSTGADDR_USE_GRP tglobaladdr:$addr)),
> (LOADI64_RI
2016 Feb 22
2
Failure to match a DAG after a minor pattern change in a custom Target
...d
> 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
> Scope
> /*31*/ OPC_MoveChild, 1,
> /*33*/ OPC_CheckOpcode, TARGET_VAL(ISD::ADD),
> /*36*/ OPC_RecordChild0, // #2 = $base
> /*37*/ OPC_RecordChild1, // #3 = $offset
> /*38*/ OPC_MoveChild, 1,
> /*40*/ OPC_CheckOpcode, TARGET_VAL(ISD::Cons...
2012 Mar 14
2
[LLVMdev] Data/Address registers
...rsat has LSubRegs as its output operand. Both patterns have the
same complexity and they are located at different scopes. For these two
patterns, tblgen is producing the following isel opcodes:
/*3244*/ /*Scope*/ 20, /*->3265*/
/*3245*/ OPC_RecordChild1, // #1 = $b
/*3246*/ OPC_MoveChild, 1,
/*3248*/ OPC_CheckOpcode, TARGET_VAL(ISD::Constant),
/*3251*/ OPC_MoveParent,
/*3252*/ OPC_CheckType, MVT::i16,
/*3254*/ OPC_EmitConvertToTarget, 1,
/*3256*/ OPC_MorphNodeTo, TARGET_VAL(ME::AADDMri), 0,
and in the same logic chain of pattern checking, DADDri...
2012 Mar 14
0
[LLVMdev] Data/Address registers
...as its output operand. Both patterns have the same complexity and they are located at different scopes. For these two patterns, tblgen is producing the following isel opcodes:
>
> /*3244*/ /*Scope*/ 20, /*->3265*/
> /*3245*/ OPC_RecordChild1, // #1 = $b
> /*3246*/ OPC_MoveChild, 1,
> /*3248*/ OPC_CheckOpcode, TARGET_VAL(ISD::Constant),
> /*3251*/ OPC_MoveParent,
> /*3252*/ OPC_CheckType, MVT::i16,
> /*3254*/ OPC_EmitConvertToTarget, 1,
> /*3256*/ OPC_MorphNodeTo, TARGET_VAL(ME::AADDMri), 0,
>
> and in the same logic...
2012 Mar 07
0
[LLVMdev] Data/Address registers
On Mar 7, 2012, at 6:23 AM, Ivan Llopard <ivanllopard at gmail.com> wrote:
> Hi Jim,
>
> Thanks for your response.
>
> Le 06/03/2012 22:54, Jim Grosbach a écrit :
>> Hi Ivan,
>> On Mar 3, 2012, at 4:48 AM, Ivan Llopard<ivanllopard at gmail.com> wrote:
>>
>>> Hi,
>>>
>>> I'm facing a problem in llvm while porting it
2012 Mar 07
2
[LLVMdev] Data/Address registers
Hi Jim,
Thanks for your response.
Le 06/03/2012 22:54, Jim Grosbach a écrit :
> Hi Ivan,
> On Mar 3, 2012, at 4:48 AM, Ivan Llopard<ivanllopard at gmail.com> wrote:
>
>> Hi,
>>
>> I'm facing a problem in llvm while porting it to a new target and I'll
>> need some support.
>> We have 2 kind of register, one for general purposes (i.e.
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