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
On Wed, May 20, 2009 at 1:29 PM, Chris Lattner <clattner at apple.com> wrote:>> 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}.But in any case, it doesn't really make sense; wouldn't any value of type {} fold to the constant "{} {}"? If you need an opaque value, i8* seems much more appropriate. -Eli
Chris Lattner wrote:> 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}.Okay then. I've just posted a patch to llvm-commits which would do that: http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20090518/077934.html Nick
On May 23, 2009, at 12:04 PM, Nick Lewycky wrote:>> >> That sounds like a serious bug then: {} should be a first class value >> just like {i32}. > > Okay then. I've just posted a patch to llvm-commits which would do > that: > http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20090518/077934.htmlWhy not separate the two patches: making {} legal shouldn't be tied to the new MD type switchover. -Chris
On May 20, 2009, at 1:46 PM, Eli Friedman wrote:> On Wed, May 20, 2009 at 1:29 PM, Chris Lattner <clattner at apple.com> > wrote: >>> 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}. > > But in any case, it doesn't really make sense; wouldn't any value of > type {} fold to the constant "{} {}"? If you need an opaque value, > i8* seems much more appropriate.Or better yet, {} undef. :) This is a vacuous truth, but it doesn't mean that we don't have to use it and perform the substitution. Per design, if someone did that transformation, the IR would still be correct, just not very useful. -Chris