This revision was automatically updated to reflect the committed changes.
Closed by commit rL316988: [CodeGen] Propagate may-alias'ness of lvalues with
TBAA info (authored by kosarev).
Changed prior to commit:
https://reviews.llvm.org/D39008?vs=120828&id=120958#toc
Repository:
rL LLVM
https
rjmccall accepted this revision.
rjmccall added a comment.
This revision is now accepted and ready to land.
LGTM.
https://reviews.llvm.org/D39008
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/
kosarev updated this revision to Diff 120828.
kosarev added a comment.
- Fixed comparing and hashing of TBAA access descriptors.
- Rebased on top of https://reviews.llvm.org/D39177.
Thanks John!
https://reviews.llvm.org/D39008
Files:
lib/CodeGen/CGExpr.cpp
lib/CodeGen/CGObjCRuntime.cpp
l
rjmccall added a comment.
Looks good, but you missed updating equality/hashing for the new Kind field.
Comment at: lib/CodeGen/CodeGenTBAA.h:71
AccessType == Other.AccessType &&
Offset == Other.Offset;
}
This needs to factor in the Ki
kosarev updated this revision to Diff 120675.
kosarev added a comment.
Reworked to distinct may-alias accesses from ordinary ones with an explicit
'kind' field.
https://reviews.llvm.org/D39008
Files:
lib/CodeGen/CGExpr.cpp
lib/CodeGen/CGObjCRuntime.cpp
lib/CodeGen/CGOpenMPRuntime.cpp
l
rjmccall added a comment.
Sure, that makes sense to me.
John.
Repository:
rL LLVM
https://reviews.llvm.org/D39008
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
kosarev added a comment.
Yes, I don't like it too when it comes to comparing pointers to metadata nodes
in an attempt to figure out what kind of access we are dealing with.
What concerns me is that there may be other kinds of TBAA descriptors that are
neither ordinary nor may-alias ones. For ex
kosarev added a comment.
I suspect this is supposed to be in this diff:
In https://reviews.llvm.org/D38796#906887, @rjmccall wrote:
> I think probably the best solution is to track may-alias-ness explicitly in
> the TBAAAccessInfo instead of relying in the frontend on being able to
> distingui
kosarev added a comment.
Now that https://reviews.llvm.org/D38796 is comitted and added the
tbaa-cast.cpp test case to the mainline, we fail on it with this patch applied.
The reason is that we have no special TBAA type node for may-alias accesses, so
everything that ever been a potential acces
rjmccall accepted this revision.
rjmccall added a comment.
This revision is now accepted and ready to land.
Well, I've been agreeing so far that it makes sense to propagate TBAA
information separately from LValueBaseInfo, and this seems like a logical part
of that, so okay.
Repository:
rL LL
kosarev created this revision.
kosarev added a project: clang.
This patch fixes various places in clang to propagate may-alias TBAA access
descriptors during construction of lvalues, thus eliminating the need for the
LValueBaseInfo::MayAlias flag.
This is part of https://reviews.llvm.org/D38126
11 matches
Mail list logo
