Phil Tomson via llvm-dev
2016-Jan-07 21:25 UTC
[llvm-dev] 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), >> "! RELADDR $spoff, $dst", >> [(XSTGRELADDR GPRC:$spoff, GPRC: >> $dst)]>; >> } >> >> >> > Remove the "dst" operand from XSTGRELADDR and try something like > [(set GPRC:$dst, (XSTGRELADDR GPRC:$spoff))] > >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 SDT_RELADDR : SDTypeProfile<1, 2, [SDTCisInt<0>, SDTCisSameAs<0, 1>]>; def XSTGRELADDR : SDNode<"XSTGISD::RELADDR", SDT_RELADDR>; Phil -Krzysztof> > > -- > Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted > by The Linux Foundation > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160107/9303b8a6/attachment.html>
Krzysztof Parzyszek via llvm-dev
2016-Jan-07 21:35 UTC
[llvm-dev] TableGen error message: top-level forms in instruction pattern should have void types
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 SDT_RELADDR : SDTypeProfile<1, 2, [SDTCisInt<0>, > SDTCisSameAs<0, 1>]>; > def XSTGRELADDR : SDNode<"XSTGISD::RELADDR", SDT_RELADDR>;The problem is that the pattern that you use in the instruction definition cannot have any value. That is, the top node has to consume all values produced by the nodes below it. The node XSTGRELADDR does have a value, and so it cannot be the top node. If the intent is to have the second operand as the target register for that value, it shouldn't be an operand to the SDNode, and in the instruction definition it should be listed in the (outs) list. If the second operand is not an output operand, then the RelAddr instruction should have some additional operand in (outs) and use "set ..." in the pattern, or have some other consumer as the top node in the selection pattern. -Krzysztof -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation
Phil Tomson via llvm-dev
2016-Jan-07 22:54 UTC
[llvm-dev] 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 SDT_RELADDR : SDTypeProfile<1, 2, [SDTCisInt<0>, >> SDTCisSameAs<0, 1>]>; >> def XSTGRELADDR : SDNode<"XSTGISD::RELADDR", SDT_RELADDR>; >> > > The problem is that the pattern that you use in the instruction definition > cannot have any value. That is, the top node has to consume all values > produced by the nodes below it. The node XSTGRELADDR does have a value, > and so it cannot be the top node. > If the intent is to have the second operand as the target register for > that value, it shouldn't be an operand to the SDNode, and in the > instruction definition it should be listed in the (outs) list. If the > second operand is not an output operand, then the RelAddr instruction > should have some additional operand in (outs) and use "set ..." in the > pattern, or have some other consumer as the top node in the selection > pattern. > > >Let me explain what I'm trying to achieve: In certain relocation modes we need to have addresses for symbols be relative to a special pointer register we call GRP. For example, let's say we want to access a global variable called 'answer'. The relevant part of the .ll file looks like: @answer = addrspace(4) global i32 42, align 4 @two = addrspace(3) global i32 2, align 4 @seven = addrspace(2) global i32 7, align 4 @xint = common global i32 0, align 4 @y = global [1 x i32*] [i32* @xint], align 8 ; Function Attrs: nounwind uwtable define i32 @main(i32 %argc, i8** %argv) #0 { entry: %argc.addr = alloca i32, align 4 %argv.addr = alloca i8**, align 8 %bint = alloca i32, align 4 %cint = alloca i32, align 4 %a = alloca i32**, align 8 %b = alloca i32*, align 8 store i32 %argc, i32* %argc.addr, align 4 store i8** %argv, i8*** %argv.addr, align 8 %0 = load i32 addrspace(4)* @answer, align 4 store i32 %0, i32* @xint, align 4 ... Currently this produces the following assembly code: .Ltmp0: .cfi_def_cfa_offset 48 store r510, r509, 0, 64 .Ltmp1: .cfi_offset 510, -48 bitop1 r510, r509, 0, OR, 64 .Ltmp2: .cfi_def_cfa_register 510 store r0, r510, 44, 32 store r1, r510, 32, 64 movimm r0, %hi(xint), 64 movimmshf32 r0, r0, %lo(xint) movimm r1, %rel(answer), 64 #<--- relevant lines load r1, r1, 0, 32 #<--- ... (%rel is a macro that returns the delta from the global section to the 'answer' symbol) Instead of that last load instruction there, I want it to be: load r1, GRP, r1, 32 # r1 <-mem[GRP+r1] GRP is what we call the Global Relocation Pointer - it holds the address of the global address segment. So what this should do is load the contents pointed to by the address (GRP+r1) into r1. Of course, this is only if a non-static relocation model is chosen via commandline options. Phil -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160107/690d3ede/attachment-0001.html>
Reasonably Related Threads
- TableGen error message: top-level forms in instruction pattern should have void types
- Expanding a PseudoOp and accessing the DAG
- TableGen error message: top-level forms in instruction pattern should have void types
- TableGen error message: top-level forms in instruction pattern should have void types
- Expanding a PseudoOp and accessing the DAG