On May 8, 2013, at 12:51 PM, Eric Christopher <echristo at gmail.com> wrote:> On Wed, May 8, 2013 at 11:32 AM, Nadav Rotem <nrotem at apple.com> wrote: >> >> On May 8, 2013, at 11:07 AM, dag at cray.com wrote: >> >> It might be as simple as adding >> an IR-level predicated load and predicated store, I'm not sure. >> >> >> I think that selects on the inputs+outputs of instructions is a good >> abstraction, and I don't think that we need to add a mask operand to every >> LLVM IR instruction. However, we do need support for masked load/stores, and >> I think that we should implement them as target independent intrinsics. I >> don't want to change the generic LLVM IR Load/Store instructions because I >> don't want to modify all of the existing optimizations and I also don't want >> other users of the compiler to pay for this complexity. >> > > First statement: I'm not disagreeing. :) > > That said, wouldn't a new intrinsic necessarily require all of the > passes to handle it? I'm just curious what you see the tradeoffs being > here. I'd have though adding a mask to Load/Store that just isn't > handled would be equivalent? > > -ericHi Eric, Most passes won't have to handle the load/store intrinsics because they will look like a regular function calls that read/write from memory. We don't need to change Reg2Mem or other passes that really can't do anything about masked memory operations. On the other hand, If we do change the Load/Store instruction we will have to review all of our existing optimizations. For example, some optimizations assume that a store instruction actually writes and invalidates the memory location. However, this assumption is incorrect if we are using a mask. Thanks, Nadav -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130508/80b3906b/attachment.html>
Nadav Rotem <nrotem at apple.com> writes:> Most passes won't have to handle the load/store intrinsics because > they will look like a regular function calls that read/write from > memory. We don't need to change Reg2Mem or other passes that really > can't do anything about masked memory operations. On the other hand, > If we do change the Load/Store instruction we will have to review all > of our existing optimizations. For example, some optimizations assume > that a store instruction actually writes and invalidates the memory > location. However, this assumption is incorrect if we are using a > mask.Yes, this makes sense. What happens if we add a new first-class IR instruction? I suppose passes that have visitor-like behavior will have to add code to handle it, but that code could simply treat it like an intrinsic, an unknown black box. I suppose that fact that intrinsics can be attributed so passes automatically assume they read and/or write memory is an advantage in that nothing special has to be done to passes to make them handle it conservatively. Just thinking out loud. There's something not quite sitting right with me about making masked load and store be intrinsics but I'm not sure what it is. It's likely due to not completely understanding the semantics of generic intrinsics. I would like to know how people determine whether a new instruction-like IR change should take the form of an intrinsics or a first-class Instruction. -David
On Wed, May 8, 2013 at 1:48 PM, Nadav Rotem <nrotem at apple.com> wrote:> > On May 8, 2013, at 12:51 PM, Eric Christopher <echristo at gmail.com> wrote: > > On Wed, May 8, 2013 at 11:32 AM, Nadav Rotem <nrotem at apple.com> wrote: > > > On May 8, 2013, at 11:07 AM, dag at cray.com wrote: > > It might be as simple as adding > an IR-level predicated load and predicated store, I'm not sure. > > > I think that selects on the inputs+outputs of instructions is a good > abstraction, and I don't think that we need to add a mask operand to every > LLVM IR instruction. However, we do need support for masked load/stores, and > I think that we should implement them as target independent intrinsics. I > don't want to change the generic LLVM IR Load/Store instructions because I > don't want to modify all of the existing optimizations and I also don't want > other users of the compiler to pay for this complexity. > > > First statement: I'm not disagreeing. :) > > That said, wouldn't a new intrinsic necessarily require all of the > passes to handle it? I'm just curious what you see the tradeoffs being > here. I'd have though adding a mask to Load/Store that just isn't > handled would be equivalent? > > -eric > > > Hi Eric, > > Most passes won't have to handle the load/store intrinsics because they will > look like a regular function calls that read/write from memory. We don't > need to change Reg2Mem or other passes that really can't do anything about > masked memory operations. On the other hand, If we do change the Load/Store > instruction we will have to review all of our existing optimizations. For > example, some optimizations assume that a store instruction actually writes > and invalidates the memory location. However, this assumption is incorrect > if we are using a mask. >I can almost see that, but how is the intrinsic any different from a conservative width for stores/loads where they're not handled by an optimization pass? I'm assuming I'm missing something here. -eric
On May 8, 2013, at 1:59 PM, Eric Christopher <echristo at gmail.com> wrote:> I can almost see that, but how is the intrinsic any different from a > conservative width for stores/loads where they're not handled by an > optimization pass? I'm assuming I'm missing something here. > > -ericI don't understand what you mean by "conservative width". -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130508/3ab8b040/attachment.html>