search for: typebasedaaresult

...t; group. A definition of that node could look like this: >> >> !9 = !{"omnipotent char", ...} >> >> We know that these two accesses should be considered no-alias as >> neither of them encloses the other; the least common type group for >> them is !9. TypeBasedAAResult::Aliases() and >> MDNode::getMostGenericTBAA() respond accordingly and all is good. >> >> Then, let's change the definition for the node !9: >> >> !9 = !{"int", ...} >> >> Now it doesn't look like a type group, but rather a structure memb...

...escriptors, !5 and !7, refer to node !9 as their type group. A definition of that node could look like this: !9 = !{"omnipotent char", ...} We know that these two accesses should be considered no-alias as neither of them encloses the other; the least common type group for them is !9. TypeBasedAAResult::Aliases() and MDNode::getMostGenericTBAA() respond accordingly and all is good. Then, let's change the definition for the node !9: !9 = !{"int", ...} Now it doesn't look like a type group, but rather a structure member. And nodes !5 and !7 now look as descriptors for structu...

...preserve TBAA > information. > > The point is, our approach does not try to describe accesses as (type, > offset) pairs and instead represents access sequences explicitly beginning > from the base type followed by field descriptors, which is what makes the > approach so flexible. TypeBasedAAResult::Aliases() and > MDNode::getMostGenericTBAA() are a bit more complex than they used to be > (they actually use the same internal function), but rely exclusively on > linear scans of access sequences unless we have a situation when have to > check if one of the accessed types is the type...

...art of the next. This will not be true for unions." Staring at the langref, i don't see where it assumes this. it is just offset, size, tbaa type, which seems correct to me. If you mean "the implementation assumes", then yeah, the implementation should just be fixed. "In TypeBasedAAResult::alias, we will also have to deal with the fact that unions have multiple members all at offset 0. This means that, unlike structs, the compiler will not be able to tell which member of the union the memory reference actually used. To deal with this, TypeBasedAAResult::alias (and the functions it...

...e in bug 21725 (see link above). This will treat a union as if it is a struct. However, the important change to make the unions work is that the length of the memory reference will have to be taken into consideration when looking at the type based aliasing. This should be easy enough because TypeBasedAAResult::alias takes two arguments of type MemoryLocation, and they contain the size information that is needed. This should easy take care of the first two problems. In TypeBasedAAResult::alias, we will also have to deal with the fact that unions have multiple members all at offset 0. This means that,...

On Mon, Feb 13, 2017 at 10:07 AM, Hubert Tong < hubert.reinterpretcast at gmail.com> wrote: > On Mon, Feb 13, 2017 at 2:23 AM, Daniel Berlin via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> >>> I don't think this fully solves the problem -- you'll also need to fix >>> getMostGenericTBAA. That is, even if you implement the above scheme,

...me union. Furthermore, two accesses with the same base union type overlap if their offset ranges overlap. The access types do not matter. Otherwise, they are considered not to overlap and with the current approach we can't say better. This sounds like during scanning through type trees in TypeBasedAAResult::Aliases() we should just stop at the first union type we have run into and see if: a) that union is the base type of the other access and b) the offset ranges overlap. No need to traverse through any union members. Similarly, in MDNode::getMostGenericTBAA() we do not consider nodes that...

> > > > For two given access sequences we can determine if the accessed > objects are allowed to overlap by the rules of the input > language. Sadly, this is where this becomes "unlikely to want to use to replace TBAA", at least for me. It may still be a thing we want anyway. This scheme is really an encoding of C/C++ TBAA info so it can be read by LLVM and requires

On Sun, May 14, 2017 at 11:01 AM, Hal Finkel <hfinkel at anl.gov> wrote: > > On 05/14/2017 12:49 PM, Daniel Berlin wrote: > > > > On Sun, May 14, 2017 at 10:20 AM, Hal Finkel <hfinkel at anl.gov> wrote: > >> >> On 05/14/2017 11:06 AM, Daniel Berlin wrote: >> >> >> >> On Sun, May 14, 2017 at 8:37 AM, Hal Finkel <hfinkel at

...information. >> >> The point is, our approach does not try to describe accesses as (type, >> offset) pairs and instead represents access sequences explicitly beginning >> from the base type followed by field descriptors, which is what makes the >> approach so flexible. TypeBasedAAResult::Aliases() and >> MDNode::getMostGenericTBAA() are a bit more complex than they used to be >> (they actually use the same internal function), but rely exclusively on >> linear scans of access sequences unless we have a situation when have to >> check if one of the accessed t...