similar to: [LLVMdev] Storage-Only Register Class?

Hi Justin, This is a big weakness of the current SelectionDAG infrastructure. There's not a really clean way to do this. The legalizer assumes that if a type is "legal" at all, the target can do at least basic arithmetic on that type. Theoretically, your approach of setting the operations to "TargetLowering::Promote" for i8 should work. I think it would be reasonable to

Good to know, thanks! Currently I'm just not declaring an i8 register class since we only have load/store/convert available for that type. This works fine for most uses, but becomes a hassle when dealing with function parameters. For example, if the function argument is i8, the code in LowerFormalArguments sees it as an i16 since that is the next target legal type. For my target, we need

On Thu, Aug 8, 2013 at 3:59 PM, Tom Stellard <tom at stellard.net> wrote: > On Thu, Aug 08, 2013 at 01:51:53PM -0400, Justin Holewinski wrote: > > Good to know, thanks! > > > > Currently I'm just not declaring an i8 register class since we only have > > load/store/convert available for that type. This works fine for most > uses, > > but becomes a

On Thu, Aug 08, 2013 at 01:51:53PM -0400, Justin Holewinski wrote: > Good to know, thanks! > > Currently I'm just not declaring an i8 register class since we only have > load/store/convert available for that type. This works fine for most uses, > but becomes a hassle when dealing with function parameters. For example, > if the function argument is i8, the code in

On Thu, Aug 08, 2013 at 04:25:25PM -0400, Justin Holewinski wrote: > On Thu, Aug 8, 2013 at 3:59 PM, Tom Stellard <tom at stellard.net> wrote: > > > On Thu, Aug 08, 2013 at 01:51:53PM -0400, Justin Holewinski wrote: > > > Good to know, thanks! > > > > > > Currently I'm just not declaring an i8 register class since we only have > > >

It's been on the back-burner for awhile. I'll clean it up and post it for review soon. On Tue, Aug 27, 2013 at 7:48 PM, Tom Stellard <tom at stellard.net> wrote: > On Thu, Aug 08, 2013 at 04:25:25PM -0400, Justin Holewinski wrote: > > On Thu, Aug 8, 2013 at 3:59 PM, Tom Stellard <tom at stellard.net> wrote: > > > > > On Thu, Aug 08, 2013 at

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 =

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

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

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

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

> The issue is really that there is no standard math library for PTX. Well, formally, that could very well be true. Moreover, in some parts CPU math standard is impossible to accomplish on parallel architectures, consider, for example errno behavior. But here we are speaking more about practical side. And the practical side is: past 5 years CUDA claims to accelerate compute applications, and

+ Eli Friedman as he often has very insightful comments regarding back end changes. On Fri, Jan 4, 2019 at 9:03 AM Nemanja Ivanovic <nemanja.i.ibm at gmail.com> wrote: > The changes seem fine to me. I don't think this is excessively intrusive > and it accomplishes what is needed by targets whose call lowering can > introduce illegal types. > Adding Justin Bogner as the

Hi Justin, I don't understand, why, for instance, X86 backend handles pow automatically, and NVPTX should be a PITA requiring user to bring his own pow implementation. Even at a very general level, this limits the interest of users to LLVM NVPTX backend. Could you please elaborate on the rationale behind your point? Why the accuracy modes I suggested are not sufficient, in your opinion? - D.

The X86 back-end just calls into libm: // Always use a library call for pow. setOperationAction(ISD::FPOW , MVT::f32 , Expand); setOperationAction(ISD::FPOW , MVT::f64 , Expand); setOperationAction(ISD::FPOW , MVT::f80 , Expand); The issue is really that there is no standard math library for PTX. I agree that this is a pain for most users, but I

For my target, I handle incoming memory arguments by creating a store to memory (in LowerCall, [1]), then creating a fixed object on the stack and loading from it (in LowerFormalArguments[2]). This approach was based on MSP430. I now have the problem that the resulting loads in my output assembly are done assuming that the call stack looks something like: ------ MemArg ------ MemArg ------

Thanks for the info! I would be glad to hear of any issues you have encountered on this path. I tried to make sure the 3.3 release was fully compatible with the libdevice implementation shipping with 5.5 (and as far as I know, it is). It's just not an officially supported configuration. Also, I've been meaning to address your -drvcuda issue. How would you feel about making that a part

On Tue, Mar 15, 2016 at 2:21 PM, Krzysztof Parzyszek via llvm-dev < llvm-dev at lists.llvm.org> wrote: > On 3/15/2016 4:16 PM, Rail Shafigulin via llvm-dev wrote: > >> Below is the output of llc with a -debug-only=isel. As you could see the >> output type for load, store, and add changes from v4i32 to i32 during >> legalization. How can I preserve the output type to

My target doesn't support 64 bit arithmetic, so I'd like to supply definitions for adde/addc. The problem is I can't seem to figure out the magic. Here's an example of what I need to generate: # two i64s in r5/r6 and r7/r8 # result in r1/r2, carry in r3 # adde add r2, r6, r8 cmpltu r3, r2, r6 # compute carry # addc add r1, r5, r7 add r1, zero, r3 Is this

Hi, I define a customized node with customized type. The job of this customized node is to move a value from one register class to another class. I find that if there is no use of the destination register, this node will be deleted from SDAG. For some reasons, I want to keep this node. So I attach mayStore attribute to this node and I hope it will not be deleted. However, it does not work like I