dberlin added a comment.
In https://reviews.llvm.org/D31885#727167, @hfinkel wrote:
> I'm not sure this is the right way to do this; I suspect we're lumping
> together a bunch of different bugs:
>
> 1. vector types need to have tbaa which makes them alias with their element
> types [to be clear
dberlin added a comment.
In https://reviews.llvm.org/D31885#727352, @hfinkel wrote:
> > I'm not sure about the solution to #2, because i thought there were very
> > specific points in time at which the effective type could change.
>
> I think this is a key point. I'm not sure that there are spec
dberlin added a comment.
In https://reviews.llvm.org/D31885#727370, @dberlin wrote:
> In https://reviews.llvm.org/D31885#727352, @hfinkel wrote:
>
> > > I'm not sure about the solution to #2, because i thought there were very
> > > specific points in time at which the effective type could change
dberlin added a comment.
In https://reviews.llvm.org/D31885#727499, @hfinkel wrote:
> In https://reviews.llvm.org/D31885#727371, @efriedma wrote:
>
> > In https://reviews.llvm.org/D31885#727167, @hfinkel wrote:
> >
> > > I'm not sure this is the right way to do this; I suspect we're lumping
> >
dberlin added a comment.
In https://reviews.llvm.org/D31885#727519, @dberlin wrote:
> In https://reviews.llvm.org/D31885#727499, @hfinkel wrote:
>
> > In https://reviews.llvm.org/D31885#727371, @efriedma wrote:
> >
> > > In https://reviews.llvm.org/D31885#727167, @hfinkel wrote:
> > >
> > > > I'm
dberlin added a comment.
In https://reviews.llvm.org/D31885#727529, @efriedma wrote:
> > Such an effective type change must be more explicit than "i allocated
> > typeless memory, and so i can do what i want with it".
>
> How can you change the effective type of malloc'ed memory in C, if storing
dberlin added a comment.
In https://reviews.llvm.org/D30538#690699, @hans wrote:
> +1 for documenting this, but I have to leave it to the language lawyers for
> how to fomulate it.
>
> > Enables/disables the strict aliasing assumption, which assumes that objects
> > of different types do not sh
dberlin added a comment.
In https://reviews.llvm.org/D31885#730072, @rjmccall wrote:
> Thanks for CC'ing me. There are two problems here.
>
> The second is that our alias-analysis philosophy says that the fact that two
> accesses "sufficiently obviously" can alias should always override TBAA.
dberlin added a comment.
In https://reviews.llvm.org/D31885#730766, @rjmccall wrote:
> In https://reviews.llvm.org/D31885#730539, @dberlin wrote:
>
> > In https://reviews.llvm.org/D31885#730072, @rjmccall wrote:
> >
> > > Thanks for CC'ing me. There are two problems here.
> > >
> > > The second
dberlin added a comment.
> Your proposal to we simply drop TBAA from all accesses related to unions is
> extremely conservative. It means that an access through a union has to be
> treated as potentially aliasing every other visible access, at least in terms
> of their types. That level of
dberlin added a comment.
In https://reviews.llvm.org/D31885#730909, @rjmccall wrote:
> In https://reviews.llvm.org/D31885#730853, @hfinkel wrote:
>
> > > There was a deliberate decision to make TBAA conservative about type
> > > punning in LLVM because, in practice, the strict form of TBAA you t
dberlin added a comment.
In https://reviews.llvm.org/D31885#730936, @rjmccall wrote:
> In https://reviews.llvm.org/D31885#730920, @dberlin wrote:
>
> > Just so i understand: Ignoring everything else (we can't actually make
> > likelyalias work, i think the code in the bugs makes that very clear)
12 matches
Mail list logo
