Displaying 15 results from an estimated 15 matches for "opc_morphnodeto".
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
2016 Jan 15
2
Expanding a PseudoOp and accessing the DAG
...OPC_CheckPredicate, 5, // Predicate_unindexedload
> /*2249*/ OPC_CheckPredicate, 6, // Predicate_load
> /*2251*/ OPC_CheckType, MVT::i64,
> /*2253*/ OPC_EmitMergeInputChains1_0,
> /*2254*/ OPC_EmitInteger, MVT::i64, 0,
> /*2257*/ OPC_MorphNodeTo, TARGET_VAL(XSTG::LOADI64_RI),
> 0|OPFL_Chain|OPFL_MemRefs,
> 1/*#VTs*/, MVT::i64, 2/*#Ops*/, 1, 2,
> // Src: (ld:i64 (XSTGADDR_NORMAL:iPTR
> (tglobaladdr:iPTR):$addr))<<P:Predicate_unindexedload>><<P:Predicate_load>>
>...
2014 Nov 05
2
[LLVMdev] Virtual register def doesn't dominate all uses
...at the matcher table and it looks as follows:
/*4309*/ /*Scope*/ 12, /*->4322*/
/*4310*/ OPC_CheckOpcode, TARGET_VAL(MBPISD::RET_FLAG),
/*4313*/ OPC_RecordNode, // #0 = 'retflag' chained node
/*4314*/ OPC_CaptureGlueInput,
/*4315*/ OPC_EmitMergeInputChains1_0,
/*4316*/ OPC_MorphNodeTo, TARGET_VAL(MyTarget::RETL), 0|OPFL_Chain|OPFL_GlueInput|OPFL_Variadic0,
0/*#VTs*/, 0/*#Ops*/,
// Src: (retflag) - Complexity = 3
// Dst: (RETL)
/*4322*/ /*Scope*/ 11, /*->4334*/
/*4323*/ OPC_RecordNode, // #0 = $a
/*4324*/ OPC_CheckType, MVT::i3...
2012 Apr 27
0
[LLVMdev] MemRefs in a Load Instruction
...1/*#VTs*/, MVT::i32, 2/*#Ops*/, 1, 6, // Results =
#7
/*1172*/ OPC_EmitConvertToTarget, 5,
/*1174*/ OPC_EmitNode, TARGET_VAL(Hexagon::LDriw_indexed),
0|OPFL_Chain,
1/*#VTs*/, MVT::i32, 2/*#Ops*/, 4, 8, // Results =
#9
/*1183*/ OPC_MorphNodeTo, TARGET_VAL(Hexagon::COMBINE_rr),
0|OPFL_Chain|OPFL_MemRefs,
***********************************************
Any hints on how I can track this down ? The MemRefs are to be put on the
COMBINE_rr and not the loads.
Pranav
Qualcomm Innovation Center, (QuIC) is a member of the Code Aurora Forum.
2014 Nov 03
2
[LLVMdev] Virtual register def doesn't dominate all uses
Hi Quentin,
>> Yes, the dags in view-isel-dags and view-legalize-types-dags are correct (the add operations are here and are their results are used) and the dags are the same.
>
> And what about view-sched-dags?
The DAG looks like I described below (*)
> This one should give you what has been selected. So if this is not correct, you have indeed a problem in the selection
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
2012 Apr 26
2
[LLVMdev] MemRefs in a Load Instruction
Hi,
On the hexagon target, I have written a following combiner pattern.
*********************************************
def: Pat<(i64 (or (i64 (shl (i64 (extloadi32 (i32 (add IntRegs:$src1,
s11_2ExtPred:$offset1)))),
(i32 32))),
(i64 (zextloadi32 ADDRriS11_2:$src2)))),
(i64 (COMBINE_rr
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
2012 Mar 14
2
[LLVMdev] Data/Address registers
.../*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 comes right
after AADDMri (with Scope changes in the middle)
/*3285*/ OPC_RecordChild0, // #0 = $a
/*3286*/ OPC_RecordChild1, // #1 = $b
/*3287*/ OPC_Scope, 42, /*->3331*/ // 2 children in Scop...
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.
2012 Mar 14
0
[LLVMdev] Data/Address registers
...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 comes right after AADDMri (with Scope changes in the middle)
>
> /*3285*/ OPC_RecordChild0, // #0 = $a
> /*3286*/ OPC_RecordChild1, // #1 = $b
> /*3287*/ OPC_Scope, 42, /*->...
2014 Mar 09
2
[LLVMdev] Isel DAG documentation?
...irectory) 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*/, MVT::i32, 1/*#Ops*/, 0,
// Src: (globaladdr:i32):$src - Complexity = 3
// Dst: (MOVi32imm:i32 (globaladdr:i32):$src)
The first lines are fairly unimportant, but the last two show what the
DAG thinks it's d...
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 22
2
LLVM Backend Issues
Thanks Anton and Krzysztof!
Here is the dump using the -debug flag. At this point I am not making much
sense of this, would it be too much to ask if one of you could walk me
through one of these lines?
One thing that I didn't point out is that I never defined any separate
floating point registers, not sure if this will pose any issue?
Thanks again for your time!
Jeff
jeff at