similar to: [LLVMdev] Status of getPointerSize()/getPointerTy() per address space?

Awesome! What will the requirements be for the target? Is it sufficient to just override getPointerTy and add appropriate data layout strings, or will more hooks be needed? On Thu, Jul 25, 2013 at 3:41 PM, Matt Arsenault <arsenm2 at gmail.com> wrote: > > On Jul 25, 2013, at 12:33 , Justin Holewinski <justin.holewinski at gmail.com> > wrote: > > > Looking through

On Jul 25, 2013, at 12:33 , Justin Holewinski <justin.holewinski at gmail.com> wrote: > Looking through recent additions, it looks like the infrastructure exists for targets to specify a per-address-space pointer size/type, but this does not seem to be used anywhere (SelectionDAGBuilder, legalizer, etc.). What is the status of this support? Is anyone actively working on it? >

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

Hi, It seems orderings are not assigned to DAG nodes created after the DAG builder, e.g., DAG nodes created during legalization. This causes instructions being scheduled in different order than source order for O0. This is my plan to fix it: Make a utility routine that recursively assign ordering to a chain of nodes, just like what SelectionDAGBuilder::AssignOrderingToNode() does. Then add call

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

Hi Xiaoyi, Do you still see this behavior after r177525? I recently fixed several places where ordering was not propagated, including during legalization. There are probably still cases that are missed, but I'd be interested in seeing a missed case. I'm guessing it's a legalization that expands to multiple new nodes. The AssignOrdering calls in the legalizer may need to be expanded

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

Is there a way to define a register class that is storage-only? I want to have an i8 register class that I can use for loads/stores/converts, but that does not support arithmetic. It seems addOperationAction(ISD::ADD, MVT::i8, Promote) and SetPromotedToType(ISD::ADD, MVT::i8, MVT::i16) are not sufficient, as the legalizer just looks at whether or not the underlying type is legal (which it is).

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

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

I've tried all the types (both for result and Intrinsic ID), can't seem to find what cast is causing the issue here. On Fri, Jun 24, 2016 at 11:47 AM, Ryan Taylor <ryta1203 at gmail.com> wrote: > That's what I thought but I got the same error with: > > DAG.getNode(ISD::INTRINSIC_WO_CHAIN, DL, VT, > DAG.getTargetConstant(Intrinsic::my_intrinsic, DL, MVT::i16), LHS);

On 08/08/2013 02:16 PM, Justin Holewinski wrote: > Why should SelectionDAGBuilder generate an explicit bitcast for a no-op > bitcast? The bitcast operation isn't just the reinterpretation (change in the semantic) of the bits without any change in the value of the bits itself? If the size and value do not change should be fine. > By definition, no bits are changed; so if the EVTs

I'm trying to 'lower' an operation that needs to create a node in the SD that is an intrinsic call.... what is the best way to do this? I see in the DAGBuilder it calls 'setValue' which adds to the map NodeMap[V] where V is the key and the passed in SDValue is the value but I'm not sure this is a good way to do it since these are local to SelectionDAGBuilder and the

Currently LLVM only supports address calculations for a single address space(the default). This is problematic when the device pointer type is 32/64bits, but there are small distinct memories that only have 16 bits of addressing(think GPU's with small software controlled memory segments). I am proposing a modification to a few API's in SelectionDAG that I believe will fix this problem.

Dear colleagues, I'm looking if we can replace nvopencc with LLVM NVPTX in our project. It turns NVPTX won't work with the code nvopencc can handle (please see the log below). So are atomic intrinsics not supported or am I doing call in a wrong way? Thanks, - Dima. SOURCE ======== dmikushin at hp2:~> cat kernelgen_monitor.ll ; ModuleID =

Hi! Attached set of patches splits llvm.init.trampoline into an "init" phase and an "adjust" phase, as discussed on the "Go on dragonegg" thread. Thanks! -- Sanjoy Das http://playingwithpointers.com -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Split-intrinsics-and-DAG-nodes.patch Type: text/x-diff Size: 8808 bytes Desc:

On 08/08/2013 11:04 AM, David Chisnall wrote: > What happens when I link together two IR modules from different front ends that have different language-specific address spaces? I agree with Micah: if during the linking two IR modules there are incoherences (e.g. in module1 2 -> 1 and in module2 2 -> 3) then the modules are incompatible and the link process should fail. > I would be

> -----Original Message----- > From: Dmitry N. Mikushin [mailto:maemarcus at gmail.com] > Sent: Wednesday, May 16, 2012 5:44 AM > To: LLVM-Dev > Cc: Justin Holewinski > Subject: NVPTX: __iAtomicCAS support ? > > Dear colleagues, > > I'm looking if we can replace nvopencc with LLVM NVPTX in our project. > It turns NVPTX won't work with the code nvopencc

On Fri, 1 Feb 2019 at 20:08, Matt Arsenault <arsenm2 at gmail.com> wrote: > I don’t see why this would need to be an IR pass. There aren’t all that many places left using the default argument to the various pointer function that can mostly be fixed. iPTR is hopelessly broken on the tablegen side, but you wouldn’t get to that point with this. The difficulty I'm seeing is that we need