Displaying 20 results from an estimated 300 matches similar to: "TableGen error message: top-level forms in instruction pattern should have void types"
2016 Jan 08
2
TableGen error message: top-level forms in instruction pattern should have void types
On 1/7/2016 5:54 PM, Phil Tomson wrote:
> I got it to compile by changing to:
> def SDT_RELADDR : SDTypeProfile<1, 2, [SDTCisInt<0>,
> SDTCisSameAs<0, 1>]>;
> def XSTGRELADDR : SDNode<"XSTGISD::RELADDR", SDT_RELADDR>;
>
> let Uses= [GRP] in {
> def RelAddr : XSTGPseudo< (outs GPRC:$dst),
>
2016 Jan 13
2
Expanding a PseudoOp and accessing the DAG
I've got this PseudoOp defined:
def SDT_RELADDR : SDTypeProfile<1, 2, [SDTCisInt<0>, SDTCisInt<1>]>;
def XSTGRELADDR : SDNode<"XSTGISD::RELADDR", SDT_RELADDR>;
let Constraints = "$dst = $addr" in { //, Uses= [GRP] in {
def RelAddr : XSTGPseudo< (outs GPRC:$dst),
(ins i64imm:$spoff,
2016 Jan 07
2
TableGen error message: top-level forms in instruction pattern should have void types
On Thu, Jan 7, 2016 at 1:35 PM, Krzysztof Parzyszek <kparzysz at codeaurora.org
> wrote:
> On 1/7/2016 3:25 PM, Phil Tomson wrote:
>
>>
>> That's better, but now I get:
>>
>> XSTGInstrInfo.td:902:3: error: In RelAddr: XSTGRELADDR node requires
>> exactly 2 operands!
>>
>> Which makes some sense as XSTGRELADDR is defined as:
>> def
2016 Jan 07
2
TableGen error message: top-level forms in instruction pattern should have void types
On Thu, Jan 7, 2016 at 12:21 PM, Krzysztof Parzyszek via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> On 1/7/2016 1:55 PM, Phil Tomson via llvm-dev wrote:
>
>>
>> let Uses= [GRP] in {
>> def RelAddr : XSTGPseudo< (outs),
>> (ins GPRC:$spoff, GPRC:$dst),
>>
2016 Jan 13
2
Type inference in TableGen DAG patterns
Given the following definitions:
def SDT_XSTGMVINI : SDTypeProfile<1, 1, [SDTCisInt<0>]>;
def XSTGMVINI : SDNode<"XSTGISD::MVINI", SDT_XSTGMVINI>;
def SDT_RELADDR : SDTypeProfile<1, 2, []>;
def XSTGRELADDR : SDNode<"XSTGISD::RELADDR", SDT_RELADDR>;
let Constraints = "$dst = $addr", Uses= [GRP] in
2016 Jan 13
2
Expanding a PseudoOp and accessing the DAG
On Wed, Jan 13, 2016 at 2:08 PM, Krzysztof Parzyszek via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> On 1/13/2016 2:26 PM, Phil Tomson via llvm-dev wrote:
>
>> I've got this PseudoOp defined:
>>
>> def SDT_RELADDR : SDTypeProfile<1, 2, [SDTCisInt<0>, SDTCisInt<1>]>;
>> def XSTGRELADDR :
2016 Jan 15
2
Expanding a PseudoOp and accessing the DAG
On Thu, Jan 14, 2016 at 6:05 AM, Krzysztof Parzyszek <
kparzysz at codeaurora.org> wrote:
> On 1/13/2016 4:47 PM, Phil Tomson wrote:
>
>>
>> First off, I got this idea from the LLVM Cookbook chapter 8: Writing an
>> LLVM Backend: Lowering to multiple instructions. (now I'm having my
>> doubts as to whether this is the right approach)
>>
>
>
2013 Dec 20
1
[LLVMdev] spilling & restoring registers for EHReturn & return _Unwind_Reason_Code
Hi
I'm working on the XCore target and am having difficulty building libgcc.
Background:
If I use a libgcc built by llvm3.0-gcc with my current clang-llvm3.3 compiler, exceptions 'seem' to work.
Trying to rebuild libgcc however breaks exception handling - they aren't caught!
I thus assumed I needed to focus on the unwind code and particularly functions that call
2008 Jun 30
2
[LLVMdev] Implementing llvm.atomic.cmp.swap.i32 on PowerPC
Chris Lattner wrote:
> On Jun 27, 2008, at 8:27 AM, Gary Benson wrote:
> > def CMP_UNRESw : Pseudo<(outs), (ins GPRC:$rA, GPRC:$rB, i32imm:
> > $label),
> > "cmpw $rA, $rB\n\tbne- La${label}_exit",
> > [(PPCcmp_unres GPRC:$rA, GPRC:$rB, imm:
> > $label)]>;
> > }
> >
> > ...and
2008 Jul 08
0
[LLVMdev] Implementing llvm.atomic.cmp.swap.i32 on PowerPC
PPCTargetLowering::EmitInstrWithCustomInserter has a reference
to the current MachineFunction for other purposes. Can you use
MachineFunction::getRegInfo instead?
Dan
On Jul 8, 2008, at 1:56 PM, Gary Benson wrote:
> Would it be acceptable to change MachineInstr::getRegInfo from private
> to public so I can use it from
> PPCTargetLowering::EmitInstrWithCustomInserter?
>
>
2016 Sep 26
2
Incompatible type assertion from llvm-tblgen
But don't the defs for ADDR_RR and ADDR_RI also contain dags?
def ADDR_RR : Addr< 2, "SelectAddrRegReg",
(ops GPRC:$base, GPRC:$offsetreg) >;
def ADDR_RI : Addr< 2, "SelectAddrRegImm",
(ops GPRC:$base, i64imm:$offsetimm) >;
Do I need to create some other intermediate node type for a shifted address?
Phil
On
2008 Jul 11
0
[LLVMdev] Implementing llvm.atomic.cmp.swap.i32 on PowerPC
Hi Gary,
This does not patch cleanly for me (PPCISelLowering.cpp). Can you
prepare a updated patch?
Thanks,
Evan
On Jul 10, 2008, at 11:45 AM, Gary Benson wrote:
> Cool, that worked. New patch attached...
>
> Cheers,
> Gary
>
> Evan Cheng wrote:
>> Just cast both values to const TargetRegisterClass*.
>>
>> Evan
>>
>> On Jul 10, 2008, at 7:36
2008 Jul 10
0
[LLVMdev] Implementing llvm.atomic.cmp.swap.i32 on PowerPC
Just cast both values to const TargetRegisterClass*.
Evan
On Jul 10, 2008, at 7:36 AM, Gary Benson wrote:
> Evan Cheng wrote:
>> How about?
>>
>> const TargetRegisterClass *RC = is64Bit ? &PPC:GPRCRegClass :
>> &PPC:G8RCRegClass;
>> unsigned TmpReg = RegInfo.createVirtualRegister(RC);
>
> I tried something like that yesterday:
>
> const
2008 Jul 10
2
[LLVMdev] Implementing llvm.atomic.cmp.swap.i32 on PowerPC
Evan Cheng wrote:
> How about?
>
> const TargetRegisterClass *RC = is64Bit ? &PPC:GPRCRegClass :
> &PPC:G8RCRegClass;
> unsigned TmpReg = RegInfo.createVirtualRegister(RC);
I tried something like that yesterday:
const TargetRegisterClass *RC =
is64bit ? &PPC::GPRCRegClass : &PPC::G8RCRegClass;
but I kept getting this error no matter how I arranged it:
2008 Jun 30
0
[LLVMdev] Implementing llvm.atomic.cmp.swap.i32 on PowerPC
You need to insert new basic blocks and update CFG to accomplish this.
There is a hackish way to do this right now. Add a pseudo instruction
to represent this operation and mark it usesCustomDAGSchedInserter.
This means the intrinsic is mapped to a single (pseudo) node. But it
is then expanded into instructions that can span multiple basic
blocks. See
2008 Jul 08
2
[LLVMdev] Implementing llvm.atomic.cmp.swap.i32 on PowerPC
Would it be acceptable to change MachineInstr::getRegInfo from private
to public so I can use it from PPCTargetLowering::EmitInstrWithCustomInserter?
Cheers,
Gary
Evan Cheng wrote:
> Look for createVirtualRegister. These are examples in
> PPCISelLowering.cpp.
>
> Evan
> On Jul 8, 2008, at 8:24 AM, Gary Benson wrote:
>
> > Hi Evan,
> >
> > Evan Cheng wrote:
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 :
2008 Jun 27
2
[LLVMdev] Implementing llvm.atomic.cmp.swap.i32 on PowerPC
Hi all,
I'm trying to figure out how to add the instructions required for
llvm.atomic.cmp.swap.i32 on PowerPC. I figured out LWARX (patch
attached) but the other two (CMP_UNRESw and STWCX) require multiple
instructions:
let Defs = [CR0] in {
def STWCX : Pseudo<(outs), (ins GPRC:$rS, memrr:$dst, i32imm:$label),
"stwcx. $rS, $dst\n\tbne-
2007 Jan 09
2
[LLVMdev] Pattern matching questions
On Tue, 9 Jan 2007, Evan Cheng wrote:
>> - How does one deal with multiple instruction sequences in a pattern?
>> To load a constant is a two instruction sequence, but both
>> instructions only take two operands (assume that r3 is a 32-bit
>> register):
>>
>> ilhu $3, 45 # r3 = (45 << 16)
>> iohl $3, 5 # r3 |= 5
2013 Apr 12
2
[LLVMdev] TableGen list merging
Hi,
In the PPC backend, there is a "helper" class used to define instructions that implicitly define a condition register:
class isDOT {
list<Register> Defs = [CR0];
bit RC = 1;
}
and this gets used on instructions such as:
def ADDICo : DForm_2<13, (outs GPRC:$rD), (ins GPRC:$rA, s16imm:$imm),
"addic. $rD, $rA, $imm", IntGeneral,