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
Chris Lattner wrote:> 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.The verifier rejects phi nodes of {} type. Do you actually have a case where you want this to happen? Nick
On May 19, 2009, at 7:58 PM, Nick Lewycky wrote:> Chris Lattner wrote: >> 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. > > The verifier rejects phi nodes of {} type. Do you actually have a case > where you want this to happen?That sounds like a serious bug then: {} should be a first class value just like {i32}. -Chris