Rail Shafigulin via llvm-dev
2016-Feb-18 19:32 UTC
[llvm-dev] How to interpret Selection DAG error output
On Thu, Feb 18, 2016 at 11:22 AM, Jonathan Roelofs < jonathan at codesourcery.com> wrote:> > > On 2/18/16 12:19 PM, Rail Shafigulin via llvm-dev wrote: > >> >> >> On Thu, Feb 18, 2016 at 10:50 AM, Krzysztof Parzyszek via llvm-dev >> <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: >> >> On 2/18/2016 12:43 PM, Rail Shafigulin via llvm-dev wrote: >> >> >> LLVM ERROR: Cannot select: 0x3284268: glue = EsenciaISD::SET_FLAG >> 0x3283608, 0x3283710, 0x3283e48 [ORD=3] [ID=11] >> 0x3283608: i32,ch = CopyFromReg 0x3257980, 0x3283500 [ORD=1] >> [ID=9] >> 0x3283500: i32 = Register %vreg5 [ID=1] >> 0x3283710: i32 = Constant<3> [ID=2] >> 0x3283e48: i32 = Constant<20> [ID=8] >> In function: fib >> >> As far as I can understand LLVM cannot select it because the >> pattern is >> not specified. Unfortunately for me, I can't understand how to >> interpret >> this output. Would anybody be able to help me out? >> >> >> >> The DAG node that has failed selection is "SET_FLAG %vreg5, 3, 20", >> the type of the node is "glue" and all 3 arguments are i32. >> >> I understand where SET_FLAG, 3 and 20 come from, but how did you arrive >> the conclusion that %vreg5 should be part of the pattern? >> > > The hex numbers are pointers. You can see the Use of 0x3283500 in the > CopyFromReg inst, and the def is here: > > 0x3283500: i32 = Register %vreg5 [ID=1] >I think this is where I'm loosing the "thread". Based on what I'm seeing SET_FLAG has three operands, the first of which is a CopyFromReg. So how come the pattern is SET_FLAG %vreg5, 3, 20 and not SET_FLAG CopyFromReg, 3, 20? In other words how do we go from CopyFromReg to %vreg5?> It's /just/ a dag. > > > Jon > > >> >> The top line shows the node that caused the failure. The hex >> numbers on that line are the addresses of the arguments. These >> arguments are then listed below. >> >> Newer versions of LLVM show node ids instead of addresses, but AFAIK >> it was dependent on some configuration option. >> >> -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 <mailto:llvm-dev at lists.llvm.org> >> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >> >> >> >> >> -- >> Rail Shafigulin >> Software Engineer >> Esencia Technologies >> >> >> _______________________________________________ >> LLVM Developers mailing list >> llvm-dev at lists.llvm.org >> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >> >> > -- > Jon Roelofs > jonathan at codesourcery.com > CodeSourcery / Mentor Embedded >-- Rail Shafigulin Software Engineer Esencia Technologies -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160218/c11416a1/attachment.html>
Krzysztof Parzyszek via llvm-dev
2016-Feb-18 19:34 UTC
[llvm-dev] How to interpret Selection DAG error output
On 2/18/2016 1:32 PM, Rail Shafigulin wrote:> I think this is where I'm loosing the "thread". Based on what I'm seeing > SET_FLAG has three operands, the first of which is a CopyFromReg. So how > come the pattern is SET_FLAG %vreg5, 3, 20 and not SET_FLAG CopyFromReg, > 3, 20? In other words how do we go from CopyFromReg to %vreg5?CopyFromReg is a "helper" instruction meaning "use the value from this vreg". Values that are live across basic blocks are remembered in vregs, and CopyToReg and CopyFromReg are opcodes used to express it. -Krzysztof -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation
Rail Shafigulin via llvm-dev
2016-Feb-18 19:40 UTC
[llvm-dev] How to interpret Selection DAG error output
On Thu, Feb 18, 2016 at 11:34 AM, Krzysztof Parzyszek < kparzysz at codeaurora.org> wrote:> On 2/18/2016 1:32 PM, Rail Shafigulin wrote: > >> I think this is where I'm loosing the "thread". Based on what I'm seeing >> SET_FLAG has three operands, the first of which is a CopyFromReg. So how >> come the pattern is SET_FLAG %vreg5, 3, 20 and not SET_FLAG CopyFromReg, >> 3, 20? In other words how do we go from CopyFromReg to %vreg5? >> > > CopyFromReg is a "helper" instruction meaning "use the value from this > vreg". Values that are live across basic blocks are remembered in vregs, > and CopyToReg and CopyFromReg are opcodes used to express it.I see. Thanks. 0x3283608: i32,ch = CopyFromReg 0x3257980, 0x3283500 [ORD=1] [ID=9] 0x3283500: i32 = Register %vreg5 [ID=1] Based on the code above, CopyFromReg is a node at address 0x3283608, returns i32, is of type chain and takes two inputs, the second of which is a %vreg5. So what is the first parameter? In fact where can I find the definition of CopyFromReg method?> > -Krzysztof > > > -- > Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted > by The Linux Foundation >-- Rail Shafigulin Software Engineer Esencia Technologies -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160218/e4059528/attachment.html>
Jonathan Roelofs via llvm-dev
2016-Feb-18 19:42 UTC
[llvm-dev] How to interpret Selection DAG error output
On 2/18/16 12:32 PM, Rail Shafigulin wrote:> > > On Thu, Feb 18, 2016 at 11:22 AM, Jonathan Roelofs > <jonathan at codesourcery.com <mailto:jonathan at codesourcery.com>> wrote: > > > > On 2/18/16 12:19 PM, Rail Shafigulin via llvm-dev wrote: > > > > On Thu, Feb 18, 2016 at 10:50 AM, Krzysztof Parzyszek via llvm-dev > <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org> > <mailto:llvm-dev at lists.llvm.org > <mailto:llvm-dev at lists.llvm.org>>> wrote: > > On 2/18/2016 12:43 PM, Rail Shafigulin via llvm-dev wrote: > > > LLVM ERROR: Cannot select: 0x3284268: glue > EsenciaISD::SET_FLAG > 0x3283608, 0x3283710, 0x3283e48 [ORD=3] [ID=11] > 0x3283608: i32,ch = CopyFromReg 0x3257980, > 0x3283500 [ORD=1] > [ID=9] > 0x3283500: i32 = Register %vreg5 [ID=1] > 0x3283710: i32 = Constant<3> [ID=2] > 0x3283e48: i32 = Constant<20> [ID=8] > In function: fib > > As far as I can understand LLVM cannot select it > because the > pattern is > not specified. Unfortunately for me, I can't understand > how to > interpret > this output. Would anybody be able to help me out? > > > > The DAG node that has failed selection is "SET_FLAG %vreg5, > 3, 20", > the type of the node is "glue" and all 3 arguments are i32. > > I understand where SET_FLAG, 3 and 20 come from, but how did you > arrive > the conclusion that %vreg5 should be part of the pattern? > > > The hex numbers are pointers. You can see the Use of 0x3283500 in > the CopyFromReg inst, and the def is here: > > 0x3283500: i32 = Register %vreg5 [ID=1] > > > I think this is where I'm loosing the "thread". Based on what I'm seeing > SET_FLAG has three operands, the first of which is a CopyFromReg.Yes.> So how come the pattern is SET_FLAG %vreg5, 3, 20 and not SET_FLAG > CopyFromReg, 3, 20?Because it's not... the latter is a better way of understanding it. The former is incorrect.> In other words how do we go from CopyFromReg to %vreg5?Written imperatively, the DAG from the dump you pasted is: something = dunno reg = i32 Register %vreg5 [ID=1] cpy = i32,ch CopyFromReg something, reg [ORD=1] c1 = i32 Constant<3> [ID=2] c2 = i32 Constant<20> [ID=8] foo = EsenciaISD::SET_FLAG cpy, c1, c2 [ORD=3] [ID=11] where: something is 0x3257980 reg is 0x3283500 c1 is 0x3283710 c2 is 0x3283e48 foo is 0x3283608 These are just names I made up... the names don't actually exist as I've written them, but maybe that'll help your understanding? This imperative order doesn't really exist either. Because it's a DAG, and the DAG isn't necessarily flattened like that... could be flattened in many different ways. Jon> > > It's /just/ a dag. > > > Jon > > > > The top line shows the node that caused the failure. The hex > numbers on that line are the addresses of the arguments. These > arguments are then listed below. > > Newer versions of LLVM show node ids instead of addresses, > but AFAIK > it was dependent on some configuration option. > > -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 <mailto:llvm-dev at lists.llvm.org> > <mailto:llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev > > > > > -- > Rail Shafigulin > Software Engineer > Esencia Technologies > > > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org> > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev > > > -- > Jon Roelofs > jonathan at codesourcery.com <mailto:jonathan at codesourcery.com> > CodeSourcery / Mentor Embedded > > > > > -- > Rail Shafigulin > Software Engineer > Esencia Technologies-- Jon Roelofs jonathan at codesourcery.com CodeSourcery / Mentor Embedded