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. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130508/ad04dea8/attachment.html>
Nadav Rotem <nrotem at apple.com> writes:> 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.That's probably a reasonable compromise. What's the significant difference between a target independent intrinic and a new Instruction? I'm asking to puzzle out whether there is a performance/maintenance/other advantage to one over the other. -David
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
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>
On Wed, May 8, 2013 at 11:32 AM, Nadav Rotem <nrotem at apple.com> wrote:>...we do need support for masked load/stores, and > I think that we should implement them as target independent intrinsics.As I understand, one of the tricks for converting to SSA form in LLVM is to make all variable references be loads/stores, then use Mem2Reg to convert those back to registers. It seems like using intrinsics would preclude this and require the front end of the compiler to do it, which is quite a bit of work.
Jeff Bush <jeffbush001 at gmail.com> writes:> On Wed, May 8, 2013 at 11:32 AM, Nadav Rotem <nrotem at apple.com> wrote: >>...we do need support for masked load/stores, and >> I think that we should implement them as target independent intrinsics. > > As I understand, one of the tricks for converting to SSA form in LLVM > is to make all variable references be loads/stores, then use Mem2Reg > to convert those back to registers. It seems like using intrinsics > would preclude this and require the front end of the compiler to do > it, which is quite a bit of work.Yep, that is a big concern here. How difficult would it be to teach mem2reg about these new intrinsics? -David