Displaying 20 results from an estimated 900 matches similar to: "New register class and patterns"
2016 Jan 29
3
New register class and patterns
On Fri, Jan 29, 2016 at 10:22 AM, Krzysztof Parzyszek via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> On 1/28/2016 8:11 PM, Rail Shafigulin via llvm-dev wrote:
>
>>
>> Would anyone be able to figure out why this is happening? I can provide
>> more code if needed.
>>
>
> The error message should show what types have been inferred so far.
>
> You
2016 Jan 30
1
New register class and patterns
> On Jan 29, 2016, at 13:25, Rail Shafigulin via llvm-dev <llvm-dev at lists.llvm.org> wrote:
>
>
>
> I think I understand it. But looks like I have everything labelled properly. Maybe I missed something. Here are more details:
>
> defm SFEQ : SF<0x0, "l.sfeq", Escala_CC_EQ>;
>
> multiclass SF<bits<5> op2Val, string asmstr, PatLeaf
2016 Feb 04
2
New register class and patterns
>
>
>
>
> def SDTX86CmpPTest : SDTypeProfile<1, 2, [SDTCisVT<0, i32>,
> SDTCisVec<1>,
> SDTCisSameAs<2, 1>]>;
>
> This is confusing to me. This tells me that there is 1 result but and 2
> operands. But then it says that operands 2 and 1 are of the same type,
2016 Feb 04
2
New register class and patterns
It does have an output register, it's just an implicit flag register. It
still has a DAG output. I'm not sure if the allocatable bit matters at this
point for selection purposes, but it does later. Not adding a type to the
register class can also be problematic (e.g. a flag register should have i1
added to regTypes for its class).
-Matt
>
Does LLVM make an assumption that there is an
2016 Feb 03
2
New register class and patterns
On Tue, Feb 2, 2016 at 8:42 PM, Matt Arsenault <arsenm2 at gmail.com> wrote:
>
> On Feb 2, 2016, at 16:52, Rail Shafigulin <rail at esenciatech.com> wrote:
>
> def SDT_EscalaSetFlag : SDTypeProfile<0, 3, [SDTCisSameAs<0, 1>]>;
>
>
> I think for setting an implicit register, you still need to have 1 result
> here.
>
> If you look at
2016 Feb 02
2
New register class and patterns
> On Feb 1, 2016, at 16:53, Rail Shafigulin <rail at esenciatech.com> wrote:
>
>
>
> On Fri, Jan 29, 2016 at 10:03 PM, Matt Arsenault <arsenm2 at gmail.com <mailto:arsenm2 at gmail.com>> wrote:
>
> > On Jan 29, 2016, at 13:25, Rail Shafigulin via llvm-dev <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote:
> >
>
2016 Feb 05
3
New register class and patterns
>
> No, this would have to be a void side effecting instruction which is a bit
> different.
What do you mean by "void side effecting instruction"? I'm not sure I
fully understand what you mean.
The flag register is an implicit register added to the selected
> MachineInstr's operands.
Is this something that is always done by LLVM? Is it me who is telling to
LLVM
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 07
3
BPF backend with vector operations - some strange error
Hello.
I've tried to add some simple arithmetic vector operations to the BPF backend
available in the LLVM repo. Because I added in BPFRegisterInfo.td another RegisterClass
(taken from the Mips backend):
def MSA128W: RegisterClass<"BPF", [v2i64, v2f64], 128,
(sequence "W%u", 0, 31)>;
in order to support vector for example, ADD
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
2015 Apr 21
2
[LLVMdev] Why are imm shifts where imm >= width type eliminated entirely?
There can also be other “problems" like this one: http://reviews.llvm.org/D6946 <http://reviews.llvm.org/D6946>
- Matthias
> On Apr 20, 2015, at 1:44 PM, Tim Northover <t.p.northover at gmail.com> wrote:
>
>> The DAG combiner also performs the undefined shift -> undef though, so it
>> should still be OK
>
> DAG combiner doesn't really run to
2008 Oct 13
2
[LLVMdev] INSERT_SUBREG node.
On Thu, 2008-10-02 at 11:19 -0700, Evan Cheng wrote:
>
> On Oct 2, 2008, at 11:02 AM, Sanjiv.Gupta at microchip.com wrote:
>
> > What’s the value produced by an INSERT_SUBREG node? Is it a chain?
>
>
> No, insert_subreg returns a value:
>
>
> v1 = insert_subreg v2, v3, idx
>
>
> v1 and v2 will have the same type, e.g. i16, and v3 must have a
>
2008 Oct 15
2
[LLVMdev] INSERT_SUBREG node.
On Tue, 2008-10-14 at 10:19 -0700, Evan Cheng wrote:
> You need to specify sub-register == super-register, idx relationship.
> See X86RegisterInfo.td:
>
> def x86_subreg_8bit : PatLeaf<(i32 1)>;
> def x86_subreg_16bit : PatLeaf<(i32 2)>;
> def x86_subreg_32bit : PatLeaf<(i32 3)>;
>
> def : SubRegSet<1, [AX, CX, DX, BX, SP, BP, SI, DI,
>
2014 Jul 31
3
[LLVMdev] initialize register attributes in instruction definition
Hi All,
Is it possible to initialize(set up) register attributes when we define an instruction?
like
if a register is defined like this:
" class SC_Register<bits<8> register_num,
REG_FLAG SC_X,
REG_FLAG SC_Y,
REG_FLAG SC_Z,
REG_FLAG SC_W,
string asmstr> : Register<asmstr>
{
let HWEncoding{7-0} =
2010 Sep 08
5
Newbie cross tabulation issue
hi, i'm new in R and i need some help. Please, ¿do you know a function how
can process cross tables for many variables and show the result in one table
who look like this?:
+----------------------------------------------------+
|------------------ | X variable |
|----------------- | Xop1 | Xop2 | Xop3|.....|
+----------------------------------------------------+
|Yvar1 |
2012 Jul 03
3
[LLVMdev] bug in tablegen?
Not sure what you mean.
I.OutOperandList == (outs CPU16Regs:$rx)
I.InOperandList == (ins CPU16Regs:$ry, CPU16Regs:$rz)
On 07/02/2012 09:26 PM, Sean Silva wrote:
> I think you're missing the template args for `FRRR16_ins` in the first
> argument. The switch in TGParser::ParseType() doesn't cover the case
> of types with template args though... which makes me wonder what is
2008 Oct 14
0
[LLVMdev] INSERT_SUBREG node.
You need to specify sub-register == super-register, idx relationship.
See X86RegisterInfo.td:
def x86_subreg_8bit : PatLeaf<(i32 1)>;
def x86_subreg_16bit : PatLeaf<(i32 2)>;
def x86_subreg_32bit : PatLeaf<(i32 3)>;
def : SubRegSet<1, [AX, CX, DX, BX, SP, BP, SI, DI,
R8W, R9W, R10W, R11W, R12W, R13W, R14W, R15W],
[AL, CL,
2010 Sep 29
2
[LLVMdev] comparison pattern trouble
Our architecture has 1-bit boolean predicate registers.
I've defined comparison
def NErrb : InstTCE<(outs I1Regs:$op3), (ins I32Regs:$op1,I32Regs:$op2), "", [(set I1Regs:$op3, (setne I32Regs:$op1, I32Regs:$op2))]>;
But then I end up having the following bug:
Code
%0 = zext i8 %data to i32
%1 = zext i16 %crc to i32
%2 = xor i32 %1, %0
%3 = and i32 %2, 1
%4 =
2012 Jul 24
2
[LLVMdev] Instruction Encodings in TableGen
I'm starting to look into binary instruction encodings in TableGen, and I'm
a bit confused on how the instruction fields are populated. Perhaps I'm
just being dense, but I cannot see how SDAG operands are translated into
the encoding fields. Can someone please explain the following snippet from
the PPC back-end.
The AND instruction in PPC is defined as:
1011 def AND :
2012 Apr 19
2
[LLVMdev] Tablegen to match a literal in an instruction
I am trying to make some modifications to our code generator that will produce better code, but require adding new patterns.
What I am trying to do is take a register/register pattern and change it to a register/immediate.
So for example, I have this pattern:
class ILFormat<ILOpCode op, dag outs, dag ins, string asmstr, list<dag> pattern>
: Instruction {
let Namespace =