Uday Bondhugula

@dcaballe Normally, it'd be great to just have a single good lowering for memrefs for the LLVM dialect. I assume what you need out of tree is something different enough...

> The following LLVM IR instructions are currently not modeled by the LLVM dialect. Each of this is a great starter bug to implement a new Op in MLIR. >...

> Define "useful". If we count extensions like NVVM, there are literally thousands of intrinsics... It's a bit hard to define, but what I meant was "more commonly used" or...

Looks good! For 'getLiveness(Value *value)', you could instead have a ``` LivenessValueInfo *getLivenessAtOp(Operation *op) ``` to (1) avoid the situation where a Value isn't defined by an op (because it...

> @bondhugula What benefit does computing on an Operation with zero results have? IIUC, the getLiveness method is providing liveness info (live-in's and live-out's) at that program point -- as...

Thanks, everything you suggest sounds good to me. My comment on liveness at a point was due to the comment on your method LivenessValueInfo::live(). Clearly, live ranges are what you...

> Aren't we getting in the realm of needing your own AllocOp to model your memory manager instead? Adding new versions of alloc op's would appear to make the logic...

> > but that of adding a "stack" attribute. This could be looked at during conversion to the LLVM dialect to generate llvm.alloca instead of malloc without having to worry...

> > > > but that of adding a "stack" attribute. This could be looked at during conversion to the LLVM dialect to generate llvm.alloca instead of malloc without having...

Thanks. Could we unhide it? It's at least more useful for developers than many of the options currently exposed are.