llvm dev - Jul 2012 - [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
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20120702/00bedaba/attachment.html>

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>

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.
[Villmow, Micah] We've seen this to from some weird OpenCL code, in our case
it was the result of storing to a NULL pointer.
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<mailto: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<mailto: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<mailto: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<mailto:eli.friedman at gmail.com>>:
>>>>>
>>>>> On Fri, Jun 29, 2012 at 2:11 PM, Dmitry N. Mikushin
>>>>> <maemarcus at gmail.com<mailto: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<mailto: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<mailto: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<mailto: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/bd491901/attachment.html>

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<mailto: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<mailto: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<mailto: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<mailto:eli.friedman at gmail.com>>:
>>>>>
>>>>> On Fri, Jun 29, 2012 at 2:11 PM, Dmitry N. Mikushin
>>>>> <maemarcus at gmail.com<mailto: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<mailto: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<mailto: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<mailto: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.
-----------------------------------------------------------------------------------
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20120702/b3e970a9/attachment.html>

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

- 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.
> ________________________________