summaryrefslogtreecommitdiffstats
path: root/llvm/lib/Transforms/IPO/LowerBitSets.cpp
Commit message (Collapse)AuthorAgeFilesLines
* IR: New representation for CFI and virtual call optimization pass metadata.Peter Collingbourne2016-06-241-1060/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The bitset metadata currently used in LLVM has a few problems: 1. It has the wrong name. The name "bitset" refers to an implementation detail of one use of the metadata (i.e. its original use case, CFI). This makes it harder to understand, as the name makes no sense in the context of virtual call optimization. 2. It is represented using a global named metadata node, rather than being directly associated with a global. This makes it harder to manipulate the metadata when rebuilding global variables, summarise it as part of ThinLTO and drop unused metadata when associated globals are dropped. For this reason, CFI does not currently work correctly when both CFI and vcall opt are enabled, as vcall opt needs to rebuild vtable globals, and fails to associate metadata with the rebuilt globals. As I understand it, the same problem could also affect ASan, which rebuilds globals with a red zone. This patch solves both of those problems in the following way: 1. Rename the metadata to "type metadata". This new name reflects how the metadata is currently being used (i.e. to represent type information for CFI and vtable opt). The new name is reflected in the name for the associated intrinsic (llvm.type.test) and pass (LowerTypeTests). 2. Attach metadata directly to the globals that it pertains to, rather than using the "llvm.bitsets" global metadata node as we are doing now. This is done using the newly introduced capability to attach metadata to global variables (r271348 and r271358). See also: http://lists.llvm.org/pipermail/llvm-dev/2016-June/100462.html Differential Revision: http://reviews.llvm.org/D21053 llvm-svn: 273729
* Re-commit optimization bisect support (r267022) without new pass manager ↵Andrew Kaylor2016-04-221-0/+3
| | | | | | | | | | support. The original commit was reverted because of a buildbot problem with LazyCallGraph::SCC handling (not related to the OptBisect handling). Differential Revision: http://reviews.llvm.org/D19172 llvm-svn: 267231
* Revert "Initial implementation of optimization bisect support."Vedant Kumar2016-04-221-3/+0
| | | | | | | | This reverts commit r267022, due to an ASan failure: http://lab.llvm.org:8080/green/job/clang-stage2-cmake-RgSan_check/1549 llvm-svn: 267115
* Initial implementation of optimization bisect support.Andrew Kaylor2016-04-211-0/+3
| | | | | | | | | | | | This patch implements a optimization bisect feature, which will allow optimizations to be selectively disabled at compile time in order to track down test failures that are caused by incorrect optimizations. The bisection is enabled using a new command line option (-opt-bisect-limit). Individual passes that may be skipped call the OptBisect object (via an LLVMContext) to see if they should be skipped based on the bisect limit. A finer level of control (disabling individual transformations) can be managed through an addition OptBisect method, but this is not yet used. The skip checking in this implementation is based on (and replaces) the skipOptnoneFunction check. Where that check was being called, a new call has been inserted in its place which checks the bisect limit and the optnone attribute. A new function call has been added for module and SCC passes that behaves in a similar way. Differential Revision: http://reviews.llvm.org/D19172 llvm-svn: 267022
* [cfi] Support explicit sections for functions in cfi-icall.Evgeniy Stepanov2016-04-151-2/+3
| | | | | | | | | | Allow explicit section for indirectly called functions in cfi-icall. Jumptables for functions in the same type class must be contiguous, so they always go to the default text section. Fixes PR25079. llvm-svn: 266486
* LowerBitSets: Move declarations to separate namespace.Peter Collingbourne2016-04-011-0/+1
| | | | | | Should fix modules build. llvm-svn: 265176
* LowerBitSets: Don't bother to do any work if the llvm.bitset.test intrinsic ↵Peter Collingbourne2016-02-031-1/+1
| | | | | | is unused. llvm-svn: 259625
* Update to use new name alignTo().Rui Ueyama2016-01-141-1/+1
| | | | llvm-svn: 257804
* [cfi] Fix LowerBitSets on 32-bit targets.Evgeniy Stepanov2015-12-211-1/+1
| | | | | | | This code attempts to truncate IntPtrTy to i32, which may be the same type. llvm-svn: 256205
* Fix Clang-tidy modernize-use-nullptr warnings in source directories and ↵Hans Wennborg2015-10-061-3/+2
| | | | | | | | | | generated files; other minor cleanups. Patch by Eugene Zelenko! Differential Revision: http://reviews.llvm.org/D13321 llvm-svn: 249482
* [opaque pointer types] Switch a few cases of getElementType over, since I ↵David Blaikie2015-09-141-12/+12
| | | | | | had them lying around anyway llvm-svn: 247610
* Revert "[opaque pointer type] Pass GlobalAlias the actual pointer type ↵David Blaikie2015-09-141-10/+11
| | | | | | | | | | | | | | | | | rather than decomposing it into pointee type + address space" This was a flawed change - it just caused the getElementType call to be deferred until later, when we really need to remove it. Now that the IR for GlobalAliases has been updated, the root cause is addressed that way instead and this change is no longer needed (and in fact gets in the way - because we want to pass the pointee type directly down further). Follow up patches to push this through GlobalValue, bitcode format, etc, will come along soon. This reverts commit 236160. llvm-svn: 247585
* LowerBitSets: Fix non-determinism bug.Peter Collingbourne2015-09-091-4/+22
| | | | | | | | Visit disjoint sets in a deterministic order based on the maximum BitSetNM index, otherwise the order in which we visit them will depend on pointer comparisons. This was being exposed by MSan. llvm-svn: 247201
* Re-apply r247080 with order of evaluation fix.Peter Collingbourne2015-09-081-127/+406
| | | | llvm-svn: 247095
* Revert r247080, "LowerBitSets: Extend pass to support functions as bitsetPeter Collingbourne2015-09-081-406/+127
| | | | | | members." as it causes test failures on a number of bots. llvm-svn: 247088
* LowerBitSets: Extend pass to support functions as bitset members.Peter Collingbourne2015-09-081-127/+406
| | | | | | | | | | | | | | This change extends the bitset lowering pass to support bitsets that may contain either functions or global variables. A function bitset is lowered to a jump table that is laid out before one of the functions in the bitset. Also add support for non-string bitset identifier names. This allows for distinct metadata nodes to stand in for names with internal linkage, as done in D11857. Differential Revision: http://reviews.llvm.org/D11856 llvm-svn: 247080
* LowerBitSets: Add debugging output.Peter Collingbourne2015-07-291-0/+22
| | | | | | Differential Revision: http://reviews.llvm.org/D11583 llvm-svn: 243546
* LowerBitSets: Ignore bitset entries that do not directly refer to a global.Peter Collingbourne2015-06-271-3/+7
| | | | | | | | | | | | | | | | | It is possible for a global to be substituted with another global of a different type or a different kind (i.e. an alias) at IR link time. One example of this scenario is when a Microsoft ABI vtable is substituted with an alias referring to a larger vtable containing an RTTI reference. This will cause the global to be RAUW'd with a possibly bitcasted reference to the other global. This will of course also affect any references to the global in bitset metadata. The right way to handle such metadata is simply to ignore it. This is sound because the linked module should contain another copy of the bitset entries as applied to the new global. llvm-svn: 240866
* LowerBitSets: Do not assign names to aliases of unnamed bitset element objects.Peter Collingbourne2015-06-171-3/+2
| | | | | | | The restriction on unnamed aliases was removed in r239921. Mostly reverts r239590, but we keep the test. llvm-svn: 239923
* LowerBitSets: Give names to aliases of unnamed bitset element objects.Peter Collingbourne2015-06-121-2/+3
| | | | | | | | It is valid for globals to be unnamed, but aliases must have a name. To avoid creating invalid IR, we need to assign names to any aliases we create that point to unnamed objects that have been moved into combined globals. llvm-svn: 239590
* [opaque pointer type] Pass GlobalAlias the actual pointer type rather than ↵David Blaikie2015-04-291-7/+7
| | | | | | | | | | | | | decomposing it into pointee type + address space Many of the callers already have the pointer type anyway, and for the couple of callers that don't it's pretty easy to call PointerType::get on the pointee type and address space. This avoids LLParser from using PointerType::getElementType when parsing GlobalAliases from IR. llvm-svn: 236160
* [opaque pointer type] More GEP API migrations in IRBuilder usesDavid Blaikie2015-04-031-4/+5
| | | | | | | | | | | | | The plan here is to push the API changes out from the common components (like Constant::getGetElementPtr and IRBuilder::CreateGEP related functions) and just update callers to either pass the type if it's obvious, or pass null. Do this with LoadInst as well and anything else that comes up, then to start porting specific uses to not pass null anymore - this may require some refactoring in each case. llvm-svn: 234042
* [opaque pointer type] API migration for GEP constant factoriesDavid Blaikie2015-04-021-3/+4
| | | | | | | | | | | | | Require the pointee type to be passed explicitly and assert that it is correct. For now it's possible to pass nullptr here (and I've done so in a few places in this patch) but eventually that will be disallowed once all clients have been updated or removed. It'll be a long road to get all the way there... but if you have the cahnce to update your callers to pass the type explicitly without depending on a pointer's element type, that would be a good thing to do soon and a necessary thing to do eventually. llvm-svn: 233938
* LowerBitSets: Avoid reusing byte set addresses.Peter Collingbourne2015-03-191-1/+16
| | | | | | | | | | Each use of the byte array uses a different alias. This makes the backend less likely to reuse previously computed byte array addresses, improving the security of the CFI mechanism based on this pass. Differential Revision: http://reviews.llvm.org/D8455 llvm-svn: 232770
* LowerBitSets: do not use private aliases at all on Darwin.Peter Collingbourne2015-03-161-12/+17
| | | | | | | LLVM currently turns these into linker-private symbols, which can be dead stripped by the Darwin linker. llvm-svn: 232435
* LowerBitSets: Do not export symbols for bit set referenced globals on Darwin.Peter Collingbourne2015-03-141-1/+9
| | | | | | | The linker on that platform may re-order symbols or strip dead symbols, which will break bit set checks. Avoid this by hiding the symbols from the linker. llvm-svn: 232235
* DataLayout is mandatory, update the API to reflect it with references.Mehdi Amini2015-03-101-10/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Now that the DataLayout is a mandatory part of the module, let's start cleaning the codebase. This patch is a first attempt at doing that. This patch is not exactly NFC as for instance some places were passing a nullptr instead of the DataLayout, possibly just because there was a default value on the DataLayout argument to many functions in the API. Even though it is not purely NFC, there is no change in the validation. I turned as many pointer to DataLayout to references, this helped figuring out all the places where a nullptr could come up. I had initially a local version of this patch broken into over 30 independant, commits but some later commit were cleaning the API and touching part of the code modified in the previous commits, so it seemed cleaner without the intermediate state. Test Plan: Reviewers: echristo Subscribers: llvm-commits From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 231740
* Make DataLayout Non-Optional in the ModuleMehdi Amini2015-03-041-4/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: DataLayout keeps the string used for its creation. As a side effect it is no longer needed in the Module. This is "almost" NFC, the string is no longer canonicalized, you can't rely on two "equals" DataLayout having the same string returned by getStringRepresentation(). Get rid of DataLayoutPass: the DataLayout is in the Module The DataLayout is "per-module", let's enforce this by not duplicating it more than necessary. One more step toward non-optionality of the DataLayout in the module. Make DataLayout Non-Optional in the Module Module->getDataLayout() will never returns nullptr anymore. Reviewers: echristo Subscribers: resistor, llvm-commits, jholewinski Differential Revision: http://reviews.llvm.org/D7992 From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 231270
* LowerBitSets: Use byte arrays instead of bit sets to represent in-memory bit ↵Peter Collingbourne2015-03-031-64/+156
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | sets. By loading from indexed offsets into a byte array and applying a mask, a program can test bits from the bit set with a relatively short instruction sequence. For example, suppose we have 15 bit sets to lay out: A (16 bits), B (15 bits), C (14 bits), D (13 bits), E (12 bits), F (11 bits), G (10 bits), H (9 bits), I (7 bits), J (6 bits), K (5 bits), L (4 bits), M (3 bits), N (2 bits), O (1 bit) These bits can be laid out in a 16-byte array like this: Byte Offset 0123456789ABCDEF Bit 7 HHHHHHHHHIIIIIII 6 GGGGGGGGGGJJJJJJ 5 FFFFFFFFFFFKKKKK 4 EEEEEEEEEEEELLLL 3 DDDDDDDDDDDDDMMM 2 CCCCCCCCCCCCCCNN 1 BBBBBBBBBBBBBBBO 0 AAAAAAAAAAAAAAAA For example, to test bit X of A, we evaluate ((bits[X] & 1) != 0), or to test bit X of I, we evaluate ((bits[9 + X] & 0x80) != 0). This can be done in 1-2 machine instructions on x86, or 4-6 instructions on ARM. This uses the LPT multiprocessor scheduling algorithm to lay out the bits efficiently. Saves ~450KB of instructions in a recent build of Chromium. Differential Revision: http://reviews.llvm.org/D7954 llvm-svn: 231043
* LowerBitSets: Align referenced globals.Peter Collingbourne2015-02-251-22/+40
| | | | | | | | | | | | | | | | This change aligns globals to the next highest power of 2 bytes, up to a maximum of 128. This makes it more likely that we will be able to compress bit sets with a greater alignment. In many more cases, we can now take advantage of a new optimization also introduced in this patch that removes bit set checks if the bit set is all ones. The 128 byte maximum was found to provide the best tradeoff between instruction overhead and data overhead in a recent build of Chromium. It allows us to remove ~2.4MB of instructions at the cost of ~250KB of data. Differential Revision: http://reviews.llvm.org/D7873 llvm-svn: 230540
* LowerBitSets: Introduce global layout builder.Peter Collingbourne2015-02-241-10/+78
| | | | | | | | | | The builder is based on a layout algorithm that tries to keep members of small bit sets together. The new layout compresses Chromium's bit sets to around 15% of their original size. Differential Revision: http://reviews.llvm.org/D7796 llvm-svn: 230394
* LowerBitSets.cpp: Prune incorrect \param(s). [-Wdocumentation]NAKAMURA Takumi2015-02-221-6/+6
| | | | | | \param should be used as itemized. llvm-svn: 230167
* Introduce bitset metadata format and bitset lowering pass.Peter Collingbourne2015-02-201-0/+526
This patch introduces a new mechanism that allows IR modules to co-operatively build pointer sets corresponding to addresses within a given set of globals. One particular use case for this is to allow a C++ program to efficiently verify (at each call site) that a vtable pointer is in the set of valid vtable pointers for the class or its derived classes. One way of doing this is for a toolchain component to build, for each class, a bit set that maps to the memory region allocated for the vtables, such that each 1 bit in the bit set maps to a valid vtable for that class, and lay out the vtables next to each other, to minimize the total size of the bit sets. The patch introduces a metadata format for representing pointer sets, an '@llvm.bitset.test' intrinsic and an LTO lowering pass that lays out the globals and builds the bitsets, and documents the new feature. Differential Revision: http://reviews.llvm.org/D7288 llvm-svn: 230054
OpenPOWER on IntegriCloud