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

[Dmitry N. Mikushin]

Justin,

Thank you,

It is undefined address (???) only in reduced test case and was defined in original big one in first message of this thread.

- Dima.

----- Original message -----
> 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20120702/ab3e5eab/attachment.html>