FYI, I wrote up some thoughts on this here: http://nondot.org/sabre/LLVMNotes/MemoryUseMarkers.txt The intention is to allow front-ends to express things like "I know this memory is a constant in this region" and to allow the optimizer/ codegen to perform more aggressive stack slot merging. -Chris
Chris Lattner wrote:> FYI, I wrote up some thoughts on this here: > http://nondot.org/sabre/LLVMNotes/MemoryUseMarkers.txt > > The intention is to allow front-ends to express things like "I know > this memory is a constant in this region" and to allow the optimizer/ > codegen to perform more aggressive stack slot merging.Very nice! Why does @llvm.invariant.end restate the size when it already takes the call to @llvm.invariant.start as its first argument? Did you really mean to allow for the case where part of an object is still invariant and part isn't? If so, isn't it missing an offset as well? Nick
On May 19, 2009, at 12:32 AM, Nick Lewycky wrote:> Chris Lattner wrote: >> FYI, I wrote up some thoughts on this here: >> http://nondot.org/sabre/LLVMNotes/MemoryUseMarkers.txt >> >> The intention is to allow front-ends to express things like "I know >> this memory is a constant in this region" and to allow the optimizer/ >> codegen to perform more aggressive stack slot merging. > > Very nice! > > Why does @llvm.invariant.end restate the size when it already takes > the > call to @llvm.invariant.start as its first argument? Did you really > mean > to allow for the case where part of an object is still invariant and > part isn't? If so, isn't it missing an offset as well?It is basically because the invariant.start may not be the immediate operand of the invariant.end. You may end up having phi nodes connecting the two when various phi translation cases occur. -Chris
On Mon, May 18, 2009 at 3:02 PM, Chris Lattner <clattner at apple.com> wrote:> FYI, I wrote up some thoughts on this here: > http://nondot.org/sabre/LLVMNotes/MemoryUseMarkers.txt > > The intention is to allow front-ends to express things like "I know > this memory is a constant in this region" and to allow the optimizer/ > codegen to perform more aggressive stack slot merging.It seems no more prone to abuse to reserve an address space for const memory. Within a const region, all pointers to the const data are in the const address space. So rather than starting with a intrinsic, you start with a ptrcast. This would also make checking trivial stores to const regions easy in the verifier. Andrew
On May 20, 2009, at 9:25 AM, Andrew Lenharth wrote:> On Mon, May 18, 2009 at 3:02 PM, Chris Lattner <clattner at apple.com> > wrote: >> FYI, I wrote up some thoughts on this here: >> http://nondot.org/sabre/LLVMNotes/MemoryUseMarkers.txt >> >> The intention is to allow front-ends to express things like "I know >> this memory is a constant in this region" and to allow the optimizer/ >> codegen to perform more aggressive stack slot merging. > > It seems no more prone to abuse to reserve an address space for const > memory. Within a const region, all pointers to the const data are in > the const address space. So rather than starting with a intrinsic, > you start with a ptrcast. This would also make checking trivial > stores to const regions easy in the verifier.This would also make it very easy for a front-end to handle write-once data. Is there a design document about address spaces? John.
On May 20, 2009, at 9:25 AM, Andrew Lenharth wrote:> On Mon, May 18, 2009 at 3:02 PM, Chris Lattner <clattner at apple.com> > wrote: >> FYI, I wrote up some thoughts on this here: >> http://nondot.org/sabre/LLVMNotes/MemoryUseMarkers.txt >> >> The intention is to allow front-ends to express things like "I know >> this memory is a constant in this region" and to allow the optimizer/ >> codegen to perform more aggressive stack slot merging. > > It seems no more prone to abuse to reserve an address space for const > memory. Within a const region, all pointers to the const data are in > the const address space. So rather than starting with a intrinsic, > you start with a ptrcast. This would also make checking trivial > stores to const regions easy in the verifier.I don't see how this helps. Fundamentally, you have something like this: store x -> ptr <many loads and stores> load ptr ... The trick is to know that ptr does not alias the loads and stores. The further issue is that you don't know when the load is generated whether it is in the const section or not, so you couldn't bitcast its pointer operand even if you knew that. A silly C++ example is: class foo{ int ivar; foo() ... int bar() { return ivar; } }; If "bar" is called from the constructor, then the load is from a potentially varying value, if it is called from code after the constructor, it is known const (assuming the instance was declared const). -Chris