Changes in TBAATest.cpp

13680223 - [opaque pointer types] Add a FunctionCallee wrapper type, and use it.

Fri, 01 Feb 2019 02:28:03 +0000

[opaque pointer types] Add a FunctionCallee wrapper type, and use it.Recommit r352791 after tweaking DerivedTypes.h slightly, so that gccdoesn't choke on it, hopefully.Original Message:The FunctionCallee type is effectively a {FunctionType*,Value*} pair,and is a useful convenience to enable code to continue passing theresult of getOrInsertFunction() through to EmitCall, even once pointertypes lose their pointee-type.Then:- update the CallInst/InvokeInst instruction creation functions to take a Callee,- modify getOrInsertFunction to return FunctionCallee, and- update all callers appropriately.One area of particular note is the change to the sanitizercode. Previously, they had been casting the result of`getOrInsertFunction` to a `Function*` via`checkSanitizerInterfaceFunction`, and storing that. That would reportan error if someone had already inserted a function declaraction witha mismatching signature.However, in general, LLVM allows for such mismatches, as`getOrInsertFunction` will automatically insert a bitcast ifneeded. As part of this cleanup, cause the sanitizer code to do thesame. (It will call its functions using the expected signature,however they may have been declared.)Finally, in a small number of locations, callers of`getOrInsertFunction` actually were expecting/requiring that a brandnew function was being created. In such cases, I've switched them toFunction::Create instead.Differential Revision: https://reviews.llvm.org/D57315llvm-svn: 352827 List of files: /llvm-project-15.0.7/llvm/unittests/Analysis/TBAATest.cpp

fadf2506 - Revert "[opaque pointer types] Add a FunctionCallee wrapper type, and use it."

Thu, 31 Jan 2019 21:51:58 +0000

Revert "[opaque pointer types] Add a FunctionCallee wrapper type, and use it."This reverts commit f47d6b38c7a61d50db4566b02719de05492dcef1 (r352791).Seems to run into compilation failures with GCC (but not clang, whereI tested it). Reverting while I investigate.llvm-svn: 352800 List of files: /llvm-project-15.0.7/llvm/unittests/Analysis/TBAATest.cpp

f47d6b38 - [opaque pointer types] Add a FunctionCallee wrapper type, and use it.

Thu, 31 Jan 2019 20:35:56 +0000

[opaque pointer types] Add a FunctionCallee wrapper type, and use it.The FunctionCallee type is effectively a {FunctionType*,Value*} pair,and is a useful convenience to enable code to continue passing theresult of getOrInsertFunction() through to EmitCall, even once pointertypes lose their pointee-type.Then:- update the CallInst/InvokeInst instruction creation functions to take a Callee,- modify getOrInsertFunction to return FunctionCallee, and- update all callers appropriately.One area of particular note is the change to the sanitizercode. Previously, they had been casting the result of`getOrInsertFunction` to a `Function*` via`checkSanitizerInterfaceFunction`, and storing that. That would reportan error if someone had already inserted a function declaraction witha mismatching signature.However, in general, LLVM allows for such mismatches, as`getOrInsertFunction` will automatically insert a bitcast ifneeded. As part of this cleanup, cause the sanitizer code to do thesame. (It will call its functions using the expected signature,however they may have been declared.)Finally, in a small number of locations, callers of`getOrInsertFunction` actually were expecting/requiring that a brandnew function was being created. In such cases, I've switched them toFunction::Create instead.Differential Revision: https://reviews.llvm.org/D57315llvm-svn: 352791 List of files: /llvm-project-15.0.7/llvm/unittests/Analysis/TBAATest.cpp

2946cd70 - Update the file headers across all of the LLVM projects in the monorepo

Sat, 19 Jan 2019 08:50:56 +0000

Update the file headers across all of the LLVM projects in the monorepoto reflect the new license.We understand that people may be surprised that we're moving the headerentirely to discuss the new license. We checked this carefully with theFoundation's lawyer and we believe this is the correct approach.Essentially, all code in the project is now made available by the LLVMproject under our new license, so you will see that the license headersinclude that license only. Some of our contributors have contributedcode under our old license, and accordingly, we have retained a copy ofour old license notice in the top-level files in each project andrepository.llvm-svn: 351636 List of files: /llvm-project-15.0.7/llvm/unittests/Analysis/TBAATest.cpp

9a67b073 - Re-sort #include lines for unittests. This uses a slightly modified

Tue, 06 Jun 2017 11:06:56 +0000

Re-sort #include lines for unittests. This uses a slightly modifiedclang-format (https://reviews.llvm.org/D33932) to keep primary headersat the top and handle new utility headers like 'gmock' consistently withother utility headers.No other change was made. I did no manual edits, all of this isclang-format.This should allow other changes to have more clear and focused diffs,and is especially motivated by moving some headers into more focusedlibraries.llvm-svn: 304786 List of files: /llvm-project-15.0.7/llvm/unittests/Analysis/TBAATest.cpp

6de67881 - [TBAA] Don't generate invalid TBAA when merging nodes

Sun, 11 Dec 2016 20:07:25 +0000

[TBAA] Don't generate invalid TBAA when merging nodesSummary:Fix a corner case in `MDNode::getMostGenericTBAA` where we can sometimesgenerate invalid TBAA metadata.Reviewers: chandlerc, hfinkel, mehdi_amini, manmanrenSubscribers: mcrosier, llvm-commitsDifferential Revision: https://reviews.llvm.org/D26635llvm-svn: 289403 List of files: /llvm-project-15.0.7/llvm/unittests/Analysis/TBAATest.cpp

2582e690 - [TBAA] Drop support for "old style" scalar TBAA tags

Tue, 08 Nov 2016 20:46:01 +0000

[TBAA] Drop support for "old style" scalar TBAA tagsSummary:We've had support for auto upgrading old style scalar TBAA accessmetadata tags into the "new" struct path aware TBAA metadata for 3 yearsnow. The only way to actually generate old style TBAA was explicitlythrough the IRBuilder API. I think this is a good time for droppingsupport for old style scalar TBAA.I'm not removing support for textual or bitcode upgrade -- if you haveIR with the old style scalar TBAA tags that go through the AsmParser orfthe bitcode parser before LLVM sees them, they will keep working asusual.Note: %val = load i32, i32* %ptr, !tbaa !N !N = < scalar tbaa node >is equivalent to %val = load i32, i32* %ptr, !tbaa !M !N = < scalar tbaa node > !M = !{!N, !N, 0}Reviewers: manmanren, chandlerc, sunfishSubscribers: mcrosier, llvm-commits, mgornyDifferential Revision: https://reviews.llvm.org/D26229llvm-svn: 286291 List of files: /llvm-project-15.0.7/llvm/unittests/Analysis/TBAATest.cpp