[LLVMdev] [NVPTX] Backend failure in LegalizeDAG due to unimplemented expand in target lowering

Mon Jul 9 10:51:15 PDT 2012

On Sat, Jul 7, 2012 at 8:35 PM, Dmitry N. Mikushin <maemarcus at gmail.com>wrote:

> OK, thanks.
>
> For our project I implemented a similar workaround: extend each i1
> memory item to i8 and load/store i1 to i8 with a type cast. Still, the
> issue in NVPTX remains. I don't know whether NVIDIA or community
> fellows have any reasonable priority to fix it (or at least put an NYI
> assertion!). It seems to be quite more complex, than implementing
> custom lowering handler, that's why I'm not trying myself. So for now
> I filled a bug, just for record:
> http://llvm.org/bugs/show_bug.cgi?id=13291

Thanks for posting the bug.  You're right that a bit of implementation
effort will be required to fix this.

>
>
> - Dima.
>
> 2012/7/3 Yuan Lin <yulin at nvidia.com>:
> > In our (NVIDIA’s) NVVM IR spec, we define i1 having a memory size of 8
> bit.
> >
> >
> >
> >   setOperationAction(ISD::LOAD, MVT::i1, Custom);
> >
> >   setOperationAction(ISD::STORE, MVT::i1, Custom);
> >
> >
> >
> > is the right way to go.
> >
> >
> >
> > Yuan
> >
> >
> >
> >
> >
> > From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu]
> On
> > Behalf Of Justin Holewinski
> >
> >
> > Sent: Monday, July 02, 2012 9:55 AM
> > To: Dmitry N. Mikushin
> > Cc: llvmdev at cs.uiuc.edu
> > Subject: Re: [LLVMdev] [NVPTX] Backend failure in LegalizeDAG due to
> > unimplemented expand in target lowering
> >
> >
> >
> > Okay, few issues here:
> >
> >
> >
> > First, i1 is used in the NVPTX back-end to map to the predicate (.pred)
> > type.  We definitely do not want to declare this type as illegal.  The
> real
> > issue is lack of complete support for this type.  The PTX language places
> > restrictions on what can be done with .pred registers, and it looks like
> the
> > failure is here:
> >
> >
> >
> > kernelgen_hostcall.exit228:                       ; preds =
> %while.cond.i226
> >
> >   store i1 false, i1 addrspace(1)* undef, align 8
> >
> >
> >
> > Ignoring for a second that you're storing to an undefined address (???),
> the
> > back-end does not yet handle up-casting an i1 to an appropriate type for
> > storage.  The memory space is not bit-addressable, so a direct store of
> an
> > i1 does not make sense.  In the short term, I would recommend that you
> > manually zext from/to i8 and load/store those.
> >
> >
> >
> > On Sun, Jul 1, 2012 at 10:14 AM, Dmitry N. Mikushin <maemarcus at gmail.com
> >
> > wrote:
> >
> > Hi Duncan,
> >
> > Sorry I don't understand your point, could you please explain a little
> bit
> > more?
> > Why i1 should be declared illegal? Operations on byte-wide types like
> > char or bool are pretty legal, according to PTX spec:
> >
> > "Registers may be typed (signed integer, unsigned integer, floating
> > point, predicate) or untyped. Register size is restricted; aside from
> > predicate registers which are 1-bit, scalar registers have a width of
> > 8-, 16-, 32-, or 64-bits, and vector registers have a width of 16-,
> > 32-, 64-, or 128-bits. The most common use of 8-bit registers is with
> > ld, st, and cvt instructions, or as elements of vector tuples."
> >
> > Thanks,
> > - D.
> >
> >
> > 2012/6/30 Duncan Sands <baldrick at free.fr>:
> >> Hi Dmitry,
> >>
> >>>> did you declare i1 to be an illegal type?
> >>>
> >>>
> >>> No. How?
> >>
> >>
> >> I think it will be considered illegal if you don't add it to any
> >> register class.
> >>
> >> Ciao, Duncan.
> >>
> >>
> >>>
> >>> 2012/6/30 Duncan Sands <baldrick at free.fr>:
> >>>>
> >>>> Hi Dmitry,
> >>>>>
> >>>>> So instead of setOperationAction(ISD::STORE, MVT::i1, Expand); one
> >>>>> should probably do setOperationAction(ISD::STORE, MVT::i1, Custom);
> >>>>> and implement it in NVPTXTargetLowering::LowerOperation.
> >>>>>
> >>>>> But this issue makes a good point about the code efficiency: I
> suspect
> >>>>> such expansion will be very ugly in terms of performance. Probably we
> >>>>> can do much better if bool would use i32 instead of i1. I don't know
> >>>>> how to do that, though. Is it possible?
> >>>>
> >>>>
> >>>> did you declare i1 to be an illegal type?  If so, you shouldn't get
> any
> >>>> stores of i1 at this stage (you may get trunc stores to i1, but that
> is
> >>>> different).
> >>>>
> >>>> Ciao, Duncan.
> >>>>
> >>>>>
> >>>>> Anyway, if this is a defect, then it's a blocker for us, and we'd
> much
> >>>>> appreciate a fix.
> >>>>>
> >>>>> - D.
> >>>>>
> >>>>> 2012/6/29 Eli Friedman <eli.friedman at gmail.com>:
> >>>>>>
> >>>>>> On Fri, Jun 29, 2012 at 2:11 PM, Dmitry N. Mikushin
> >>>>>> <maemarcus at gmail.com> wrote:
> >>>>>>>
> >>>>>>> Hi again,
> >>>>>>>
> >>>>>>> Kind people on #llvm helped me to utilize bugpoint to reduce the
> >>>>>>> previously submitted test case. For record, it code be done with
> the
> >>>>>>> following command:
> >>>>>>>
> >>>>>>> $ bugpoint -llc-safe test.ll
> >>>>>>>
> >>>>>>> The resulting IR is attached, and it is crashing in the same way.
> Is
> >>>>>>> it a valid code?
> >>>>>>
> >>>>>>
> >>>>>> Looks like a bug in the NVPTXISelLowering.cpp: it has
> >>>>>> "setOperationAction(ISD::STORE, MVT::i1, Expand);", but the
> legalizer
> >>>>>> doesn't know how to handle that.
> >>>>>>
> >>>>>> -Eli
> >>>>>
> >>>>> _______________________________________________
> >>>>> LLVM Developers mailing list
> >>>>> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> >>>>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
> >>>>>
> >>>>
> >>>>
> >>>> _______________________________________________
> >>>> LLVM Developers mailing list
> >>>> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> >>>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
> >>
> >>
> >>
> >
> > _______________________________________________
> > LLVM Developers mailing list
> > LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
> >
> >
> >
> >
> >
> > --
> >
> > Thanks,
> >
> >
> >
> > Justin Holewinski
> >
> >
> >
> > ________________________________
> > This email message is for the sole use of the intended recipient(s) and
> may
> > contain confidential information.  Any unauthorized review, use,
> disclosure
> > or distribution is prohibited.  If you are not the intended recipient,
> > please contact the sender by reply email and destroy all copies of the
> > original message.
> > ________________________________
>

-- 

Thanks,

Justin Holewinski
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20120709/bc1c88f5/attachment.html>