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 match, > there is nothing to do. The fundamental problem is how address spaces > are handled, and specifically how they are converted, in LLVM IR. > Address space casts are currently implemented with bitcasts (in > general). While this works out for the LLVM IR type system, it does not > match the semantics of an address space cast for some targets. For PTX, > and address space cast may involve changing bits in the address. > Therefore, a bitcast is not a valid way to perform an address space > cast. We introduced target intrinsics to perform address space casts > for this purpose. But I feel that this problem is likely not specific > to PTX. A target that uses different pointer sizes for different > address spaces would be hit by this issue even more, since a bitcast > would not even be valid IR.I agree with this, probably a 'ptrcast' instruction would better fits the various cases allowing the targets to handle correctly all the cases where the size/value change. It seems that there are various 'little' problems in the way address spaces are currently handled. I think it may be useful to list the various issues in order to plan a common solution. Thanks. -Michele
This is something I proposed last year, so you might want to read up on that discussion first. You can find it here: http://lists.cs.uiuc.edu/pipermail/llvmdev/2012-September/053277.html micah> -----Original Message----- > From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] > On Behalf Of Michele Scandale > Sent: Thursday, August 08, 2013 5:39 AM > To: Justin Holewinski > Cc: LLVM Developers Mailing List > Subject: Re: [LLVMdev] Address space extension > > 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 match, there is > > nothing to do. The fundamental problem is how address spaces are > > handled, and specifically how they are converted, in LLVM IR. > > Address space casts are currently implemented with bitcasts (in > > general). While this works out for the LLVM IR type system, it does > > not match the semantics of an address space cast for some targets. > > For PTX, and address space cast may involve changing bits in the address. > > Therefore, a bitcast is not a valid way to perform an address space > > cast. We introduced target intrinsics to perform address space casts > > for this purpose. But I feel that this problem is likely not specific > > to PTX. A target that uses different pointer sizes for different > > address spaces would be hit by this issue even more, since a bitcast > > would not even be valid IR. > > I agree with this, probably a 'ptrcast' instruction would better fits the various > cases allowing the targets to handle correctly all the cases where the > size/value change. > > It seems that there are various 'little' problems in the way address spaces are > currently handled. I think it may be useful to list the various issues in order to > plan a common solution. > > Thanks. > > -Michele > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
On 08/08/2013 02:52 PM, Micah Villmow wrote:> This is something I proposed last year, so you might want to read up on that discussion first. > > You can find it here: > http://lists.cs.uiuc.edu/pipermail/llvmdev/2012-September/053277.htmlUhm... I read the discussion, probably I've not understood the problem well: the conclusion (it has been committed?) is that to handle address space conversion that imply a change in the size of pointers must be expressed as a pair ptrtoint/inttoptr. What if the address space conversione logically change also the value of the pointer? Indeed, trying to port that solution in the context of in-progress proposal: how to handle the fact that the addrspace information is logical? Is the frontend that need to produce the correct address space conversion? Why having an opaque instruction/generic-intrinsic that represent the conversion (what the conversion imply is target specific, so that each target should lower this intrinsic using the knowledge of the source and destination address space) is bad? Thanks again. -Michele
Sent from my iPhone> On Aug 8, 2013, at 5:39 AM, Michele Scandale <michele.scandale at gmail.com> wrote: > >> 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 match, >> there is nothing to do. The fundamental problem is how address spaces >> are handled, and specifically how they are converted, in LLVM IR. >> Address space casts are currently implemented with bitcasts (in >> general). While this works out for the LLVM IR type system, it does not >> match the semantics of an address space cast for some targets. For PTX, >> and address space cast may involve changing bits in the address. >> Therefore, a bitcast is not a valid way to perform an address space >> cast. We introduced target intrinsics to perform address space casts >> for this purpose. But I feel that this problem is likely not specific >> to PTX. A target that uses different pointer sizes for different >> address spaces would be hit by this issue even more, since a bitcast >> would not even be valid IR. > > I agree with this, probably a 'ptrcast' instruction would better fits the various cases allowing the targets to handle correctly all the cases where the size/value change. > > It seems that there are various 'little' problems in the way address spaces are currently handled. I think it may be useful to list the various issues in order to plan a common solution.I think the main problem is what David demonstrate earlier. That is, a pointer whose value and size don't change when cast to a different address space, but for which you must actually generate different instructions for in codegen. I think any use of addrspacecast should require metadata defining the address space hierarchy. Casting between overlapping regions in the hierarchy would be allowed. Casting between non overlapping regions would either be undefined or an error. In the example David gave with address spaces 0 and 256. Clearly there isn't a single HW instruction which can use the value of the pointer to do the right thing at run time here. You really must generate different code. Therefore in the hierarchy 0 and 256 would be defined to not overlap and the cast would be invalid. I don't know about current GPU HW but I assume that similarly casting between say a local and private pointer may not be allowed as that's a very different thing in the backend. Anyone with more knowledge feel free to correct me though. However on x86 in CL, casting between local and private is fine because both just generate ordinary load/store instructions. Therefore on x86 those regions would overlap in the memory space hierarchy. Thanks Pete> > Thanks. > > -Michele > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
On Thu, Aug 8, 2013 at 12:51 PM, Pete Cooper <peter_cooper at apple.com> wrote:> > > Sent from my iPhone > > > On Aug 8, 2013, at 5:39 AM, Michele Scandale <michele.scandale at gmail.com> > wrote: > > > >> 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 match, > >> there is nothing to do. The fundamental problem is how address spaces > >> are handled, and specifically how they are converted, in LLVM IR. > >> Address space casts are currently implemented with bitcasts (in > >> general). While this works out for the LLVM IR type system, it does not > >> match the semantics of an address space cast for some targets. For PTX, > >> and address space cast may involve changing bits in the address. > >> Therefore, a bitcast is not a valid way to perform an address space > >> cast. We introduced target intrinsics to perform address space casts > >> for this purpose. But I feel that this problem is likely not specific > >> to PTX. A target that uses different pointer sizes for different > >> address spaces would be hit by this issue even more, since a bitcast > >> would not even be valid IR. > > > > I agree with this, probably a 'ptrcast' instruction would better fits > the various cases allowing the targets to handle correctly all the cases > where the size/value change. > > > > It seems that there are various 'little' problems in the way address > spaces are currently handled. I think it may be useful to list the various > issues in order to plan a common solution. > I think the main problem is what David demonstrate earlier. That is, a > pointer whose value and size don't change when cast to a different address > space, but for which you must actually generate different instructions for > in codegen. > >The IR should be agnostic towards whether bits change or not. That is purely target-defined, and may even vary within a target.> I think any use of addrspacecast should require metadata defining the > address space hierarchy. Casting between overlapping regions in the > hierarchy would be allowed. Casting between non overlapping regions would > either be undefined or an error. >I like having such a guarantee available, but I hesitate to *require* metadata in the IR. Perhaps if the metadata doesn't exist the verifier assumes the casts are valid and the optimizers have to assume all address spaces alias?> > In the example David gave with address spaces 0 and 256. Clearly there > isn't a single HW instruction which can use the value of the pointer to do > the right thing at run time here. You really must generate different code. > Therefore in the hierarchy 0 and 256 would be defined to not overlap and > the cast would be invalid. > > I don't know about current GPU HW but I assume that similarly casting > between say a local and private pointer may not be allowed as that's a very > different thing in the backend. Anyone with more knowledge feel free to > correct me though. >For PTX, casting between two non-generic pointer types is not allowed. Even though they are treated very similarly in the back-end, the address bits are just not compatible.> > However on x86 in CL, casting between local and private is fine because > both just generate ordinary load/store instructions. Therefore on x86 those > regions would overlap in the memory space hierarchy. >Is that really what we want though? This seems like a good use-case for enabling better optimization on X86. Both local and private will ultimately be in address space 0 for the target, but you want them to be treated as disjoint as far as the optimizers are concerned since the programming model guarantees that there will not be aliasing between private and local pointers.> > Thanks > Pete > > > > Thanks. > > > > -Michele > > _______________________________________________ > > 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/20130808/96251ec5/attachment.html>
On 8 Aug 2013, at 17:51, Pete Cooper <peter_cooper at apple.com> wrote:> In the example David gave with address spaces 0 and 256. Clearly there isn't a single HW instruction which can use the value of the pointer to do the right thing at run time here. You really must generate different code. Therefore in the hierarchy 0 and 256 would be defined to not overlap and the cast would be invalid.Note that, in this case, values in address space 0 can alias ones in address space 256. A cast from address space 256 to 0 can be implemented by a single instruction, because it's just translating the segment-relative address to a linear address. The converse may be possible, if the linear address happens to reside within the segment. Probably the correct thing to do would be subtract the segment base from the linear address and then have a pointer that would trap on use if it is invalid. We have a similar issue where we are using an address space to represent fat pointers. The relevant problem that we have is that we have 64-bit and 256-bit pointers in our architecture, and it's quite difficult to persuade LLVM that it shouldn't insert bitcasts between them (and so we have a fork where we'd like to have an out-of-tree back end). In our case, we also have issues preventing GEPs from being canonicalised to use 256-bit offsets, even though only 64 bits of the base in the fat pointer are the base address, and we have no i256 type. We've hacked up SelectionDAG to have an iFATPTR type, but ideally we'd have iPTR16, iPTR32 and so on up to iPTR256 (or even iPTR512 for architectures even more weird than ours) and an explicit PTRCAST node to convert between them (currently we have INTTOPTR and PTRTOINT nodes in our SelectionDAG and special pattern matching. This is quite ugly, but it allowed us to get away without changing the bitcode format. It's not a good solution though). We'd also like something in DataLayout or similar to indicate whether a pointer is an integer or a fat pointer. A related issue is that TableGen really really likes the idea that the is-a-pointer constraint allows it to determine the type. This means that supporting atomic operations on architectures that have multiple types of pointer in SelectionDAG is very hard. David