summaryrefslogtreecommitdiffstats
path: root/llvm/lib/Analysis/MemoryDependenceAnalysis.cpp
Commit message (Collapse)AuthorAgeFilesLines
* Revamp PredIteratorCache interface to be cleaner.Daniel Berlin2015-04-211-14/+11
| | | | | | | | | | | | | Summary: This lets us use range based for loops. Reviewers: chandlerc Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D9169 llvm-svn: 235416
* Common some code from MemoryDependenceAnalysis that will be used in MemorySSADaniel Berlin2015-04-131-17/+1
| | | | llvm-svn: 234813
* [CallSite] Make construction from Value* (or Instruction*) explicit.Benjamin Kramer2015-04-101-1/+1
| | | | | | | | | | | | | | | | | | | CallSite roughly behaves as a common base CallInst and InvokeInst. Bring the behavior closer to that model by making upcasts explicit. Downcasts remain implicit and work as before. Following dyn_cast as a mental model checking whether a Value *V isa CallSite now looks like this: if (auto CS = CallSite(V)) // think dyn_cast instead of: if (CallSite CS = V) This is an extra token but I think it is slightly clearer. Making the ctor explicit has the advantage of not accidentally creating nullptr CallSites, e.g. when you pass a Value * to a function taking a CallSite argument. llvm-svn: 234601
* !invariant.load semantics with potentially clobbering callsPhilip Reames2015-03-241-0/+9
| | | | | | | | | | A load from an invariant location is assumed to not alias any otherwise potentially aliasing stores. Our implementation only applied this rule to store instructions themselves whereas they it should apply for any memory accessing instruction. This results in both FRE and PRE becoming more effective at eliminating invariant loads. Note that as a follow on change I will likely move this into AliasAnalysis itself. That's where the TBAA constant flag is handled and the semantics are essentially the same. I'd like to separate the semantic change from the refactoring and thus have extended the hack that's already in MemoryDependenceAnalysis for this change. Differential Revision: http://reviews.llvm.org/D8591 llvm-svn: 233140
* MemoryDependenceAnalysis: Don't miscompile atomicsDavid Majnemer2015-03-211-11/+4
| | | | | | | | | | | | r216771 introduced a change to MemoryDependenceAnalysis that allowed it to reason about acquire/release operations. However, this change does not ensure that the acquire/release operations pair. Unfortunately, this leads to miscompiles as we won't see an acquire load as properly memory effecting. This largely reverts r216771. This fixes PR22708. llvm-svn: 232889
* DataLayout is mandatory, update the API to reflect it with references.Mehdi Amini2015-03-101-23/+19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-2/+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
* Revert 229175Philip Reames2015-02-151-3/+1
| | | | | | This change is a logical suspect in 22587 and 22590. Given it's of minimal importanance and I can't get clang to build on my home machine, I'm reverting so that I can deal with this next week. llvm-svn: 229322
* Analysis: Canonicalize access to function attributes, NFCDuncan P. N. Exon Smith2015-02-141-5/+4
| | | | | | | | | | | | Canonicalize access to function attributes to use the simpler API. getAttributes().getAttribute(AttributeSet::FunctionIndex, Kind) => getFnAttribute(Kind) getAttributes().hasAttribute(AttributeSet::FunctionIndex, Kind) => hasFnAttribute(Kind) llvm-svn: 229192
* Minor tweak to MDAPhilip Reames2015-02-131-1/+3
| | | | | | | | | | Two minor tweaks I noticed when reading through the code: - No need to recompute begin() on every iteration. We're not modifying the instructions in this loop. - We can ignore PHINodes and Dbg intrinsics. The current code does this anyways, but it will spend slightly more time doing so and will count towards the limit of instructions in the block. It seems really silly to give up due the presence of PHIs... Differential Revision: http://reviews.llvm.org/D7624 llvm-svn: 229175
* Whitespace.Chad Rosier2015-02-061-2/+0
| | | | llvm-svn: 228397
* Refine memory dependence's notion of volatile semanticsPhilip Reames2015-01-261-16/+27
| | | | | | | | | | According to my reading of the LangRef, volatiles are only ordered with respect to other volatiles. It is entirely legal and profitable to forward unrelated loads over the volatile load. This patch implements this for GVN by refining the transition rules MemoryDependenceAnalysis uses when encountering a volatile. The added test cases show where the extra flexibility is profitable for local dependence optimizations. I have a related change (227110) which will extend this to non-local dependence (i.e. PRE), but that's essentially orthogonal to the semantic change in this patch. I have tested the two together and can confirm that PRE works over a volatile load with both changes. I will be submitting a PRE w/volatiles test case seperately in the near future. Differential Revision: http://reviews.llvm.org/D6901 llvm-svn: 227112
* Pass QueryInst down through non-local dependency calculationPhilip Reames2015-01-261-8/+13
| | | | | | | | | | | | | | This change is mostly motivated by exposing information about the original query instruction to the actual scanning work in getPointerDependencyFrom when used by GVN PRE. In a follow up change, I will use this to be more precise with regards to the semantics of volatile instructions encountered in the scan of a basic block. Worth noting, is that this change (despite appearing quite simple) is not semantically preserving. By providing more information to the helper routine, we allow some optimizations to kick in that weren't previously able to (when called from this code path.) In particular, we see that treatment of !invariant.load becomes more precise. In theory, we might see a difference with an ordered/atomic instruction as well, but I'm having a hard time actually finding a test case which shows that. Test wise, I've included new tests for !invariant.load which illustrate this difference. I've also included some updated TBAA tests which highlight that this change isn't needed for that optimization to kick in - it's handled inside alias analysis itself. Eventually, it would be nice to factor the !invariant.load handling inside alias analysis as well. Differential Revision: http://reviews.llvm.org/D6895 llvm-svn: 227110
* [REFACTOR] Push logic from MemDepPrinter into getNonLocalPointerDependencyPhilip Reames2015-01-091-14/+21
| | | | | | | | Previously, MemDepPrinter handled volatile and unordered accesses without involving MemoryDependencyAnalysis. By making a slight tweak to the documented interface - which is respected by both callers - we can move this responsibility to MDA for the benefit of any future callers. This is basically just cleanup. In the future, we may decide to extend MDA's non local dependency analysis to return useful results for ordered or volatile loads. I believe (but have not really checked in detail) that local dependency analyis does get useful results for ordered, but not volatile, loads. llvm-svn: 225483
* [Refactor] Have getNonLocalPointerDependency take the query instructionPhilip Reames2015-01-091-2/+46
| | | | | | | | | | Previously, MemoryDependenceAnalysis::getNonLocalPointerDependency was taking a list of properties about the instruction being queried. Since I'm about to need one more property to be passed down through the infrastructure - I need to know a query instruction is non-volatile in an inner helper - fix the interface once and for all. I also added some assertions and behaviour clarifications around volatile and ordered field accesses. At the moment, this is mostly to document expected behaviour. The only non-standard instructions which can currently reach this are atomic, but unordered, loads and stores. Neither ordered or volatile accesses can reach here. The call in GVN is protected by an isSimple check when it first considers the load. The calls in MemDepPrinter are protected by isUnordered checks. Both utilities also check isVolatile for loads and stores. llvm-svn: 225481
* [PM] Split the AssumptionTracker immutable pass into two separate APIs:Chandler Carruth2015-01-041-6/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | a cache of assumptions for a single function, and an immutable pass that manages those caches. The motivation for this change is two fold. Immutable analyses are really hacks around the current pass manager design and don't exist in the new design. This is usually OK, but it requires that the core logic of an immutable pass be reasonably partitioned off from the pass logic. This change does precisely that. As a consequence it also paves the way for the *many* utility functions that deal in the assumptions to live in both pass manager worlds by creating an separate non-pass object with its own independent API that they all rely on. Now, the only bits of the system that deal with the actual pass mechanics are those that actually need to deal with the pass mechanics. Once this separation is made, several simplifications become pretty obvious in the assumption cache itself. Rather than using a set and callback value handles, it can just be a vector of weak value handles. The callers can easily skip the handles that are null, and eventually we can wrap all of this up behind a filter iterator. For now, this adds boiler plate to the various passes, but this kind of boiler plate will end up making it possible to port these passes to the new pass manager, and so it will end up factored away pretty reasonably. llvm-svn: 225131
* Remove redundant assignment.Tilmann Scheller2014-12-191-1/+0
| | | | | | Found with the Clang static analyzer. llvm-svn: 224570
* Relax an assert a bit to avoid a crash on unreachable code.Rafael Espindola2014-12-011-1/+1
| | | | | | Patch by Duncan Exon Smith with a small tweak by me. llvm-svn: 222984
* Update SetVector to rely on the underlying set's insert to return a ↵David Blaikie2014-11-191-1/+1
| | | | | | | | | | | | | pair<iterator, bool> This is to be consistent with StringSet and ultimately with the standard library's associative container insert function. This lead to updating SmallSet::insert to return pair<iterator, bool>, and then to update SmallPtrSet::insert to return pair<iterator, bool>, and then to update all the existing users of those functions... llvm-svn: 222334
* Silence a -Wsign-compare warning. NFC.Aaron Ballman2014-10-021-2/+2
| | | | llvm-svn: 218868
* [MemoryDepAnalysis] Fix compile time slowdownBruno Cardoso Lopes2014-10-011-0/+22
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | - Problem One program takes ~3min to compile under -O2. This happens after a certain function A is inlined ~700 times in a function B, inserting thousands of new BBs. This leads to 80% of the compilation time spent in GVN::processNonLocalLoad and MemoryDependenceAnalysis::getNonLocalPointerDependency, while searching for nonlocal information for basic blocks. Usually, to avoid spending a long time to process nonlocal loads, GVN bails out if it gets more than 100 deps as a result from MD->getNonLocalPointerDependency. However this only happens *after* all nonlocal information for BBs have been computed, which is the bottleneck in this scenario. For instance, there are 8280 times where getNonLocalPointerDependency returns deps with more than 100 bbs and from those, 600 times it returns more than 1000 blocks. - Solution Bail out early during the nonlocal info computation whenever we reach a specified threshold. This patch proposes a 100 BBs threshold, it also reduces the compile time from 3min to 23s. - Testing The test-suite presented no compile nor execution time regressions. Some numbers from my machine (x86_64 darwin): - 17s under -Oz (which avoids inlining). - 1.3s under -O1. - 2m51s under -O2 ToT *** 23s under -O2 w/ Result.size() > 100 - 1m54s under -O2 w/ Result.size() > 500 With NumResultsLimit = 100, GVN yields the same outcome as in the unlimited 3min version. http://reviews.llvm.org/D5532 rdar://problem/18188041 llvm-svn: 218792
* Make use of @llvm.assume in ValueTracking (computeKnownBits, etc.)Hal Finkel2014-09-071-1/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This change, which allows @llvm.assume to be used from within computeKnownBits (and other associated functions in ValueTracking), adds some (optional) parameters to computeKnownBits and friends. These functions now (optionally) take a "context" instruction pointer, an AssumptionTracker pointer, and also a DomTree pointer, and most of the changes are just to pass this new information when it is easily available from InstSimplify, InstCombine, etc. As explained below, the significant conceptual change is that known properties of a value might depend on the control-flow location of the use (because we care that the @llvm.assume dominates the use because assumptions have control-flow dependencies). This means that, when we ask if bits are known in a value, we might get different answers for different uses. The significant changes are all in ValueTracking. Two main changes: First, as with the rest of the code, new parameters need to be passed around. To make this easier, I grouped them into a structure, and I made internal static versions of the relevant functions that take this structure as a parameter. The new code does as you might expect, it looks for @llvm.assume calls that make use of the value we're trying to learn something about (often indirectly), attempts to pattern match that expression, and uses the result if successful. By making use of the AssumptionTracker, the process of finding @llvm.assume calls is not expensive. Part of the structure being passed around inside ValueTracking is a set of already-considered @llvm.assume calls. This is to prevent a query using, for example, the assume(a == b), to recurse on itself. The context and DT params are used to find applicable assumptions. An assumption needs to dominate the context instruction, or come after it deterministically. In this latter case we only handle the specific case where both the assumption and the context instruction are in the same block, and we need to exclude assumptions from being used to simplify their own ephemeral values (those which contribute only to the assumption) because otherwise the assumption would prove its feeding comparison trivial and would be removed. This commit adds the plumbing and the logic for a simple masked-bit propagation (just enough to write a regression test). Future commits add more patterns (and, correspondingly, more regression tests). llvm-svn: 217342
* Fix MemoryDependenceAnalysis in cases where QueryInstr is a CmpXchg or a ↵Robin Morisset2014-09-021-4/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | AtomicRMW Summary: MemoryDependenceAnalysis is currently cautious when the QueryInstr is an atomic load or store, but I forgot to check for atomic cmpxchg/atomicrmw. This patch is a way of fixing that, and making it less brittle (i.e. no risk that I forget another possible kind of atomic, even if the IR ends up changing in the future), by adding a fallback checking mayReadOrWriteFromMemory. Thanks to Philip Reames for finding this bug and suggesting this solution in http://reviews.llvm.org/D4845 Sadly, I don't see how to add a test for this, since the passes depending on MemoryDependenceAnalysis won't trigger for an atomic rmw anyway. Does anyone see a way for testing it? Test Plan: none possible at first sight Reviewers: jfb, reames Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D5019 llvm-svn: 216940
* Fix typos in comments, NFCRobin Morisset2014-08-291-1/+1
| | | | | | | | | | | | | | Summary: Just fixing comments, no functional change. Test Plan: N/A Reviewers: jfb Subscribers: mcrosier, llvm-commits Differential Revision: http://reviews.llvm.org/D5130 llvm-svn: 216784
* Relax the constraint more in MemoryDependencyAnalysis.cppRobin Morisset2014-08-291-6/+40
| | | | | | | | Even loads/stores that have a stronger ordering than monotonic can be safe. The rule is no release-acquire pair on the path from the QueryInst, assuming that the QueryInst is not atomic itself. llvm-svn: 216771
* Use range based for loops to avoid needing to re-mention SmallPtrSet size.Craig Topper2014-08-241-27/+18
| | | | llvm-svn: 216351
* Answer to Philip Reames commentsRobin Morisset2014-08-181-6/+27
| | | | | | | | | | - add check for volatile (probably unneeded, but I agree that we should be conservative about it). - strengthen condition from isUnordered() to isSimple(), as I don't understand well enough Unordered semantics (and it also matches the comment better this way) to be confident in the previous behaviour (thanks for catching that one, I had missed the case Monotonic/Unordered). - separate a condition in two. - lengthen comment about aliasing and loads - add tests in GVN/atomic.ll llvm-svn: 215943
* Weak relaxing of the constraints on atomics in MemoryDependencyAnalysisRobin Morisset2014-08-181-4/+22
| | | | | | | Monotonic accesses do not have to kill the analysis, as long as the QueryInstr is not itself atomic. llvm-svn: 215942
* AA metadata refactoring (introduce AAMDNodes)Hal Finkel2014-07-241-13/+16
| | | | | | | | | | | | | | | | | | | | In order to enable the preservation of noalias function parameter information after inlining, and the representation of block-level __restrict__ pointer information (etc.), additional kinds of aliasing metadata will be introduced. This metadata needs to be carried around in AliasAnalysis::Location objects (and MMOs at the SDAG level), and so we need to generalize the current scheme (which is hard-coded to just one TBAA MDNode*). This commit introduces only the necessary refactoring to allow for the introduction of other aliasing metadata types, but does not actually introduce any (that will come in a follow-up commit). What it does introduce is a new AAMDNodes structure to hold all of the aliasing metadata nodes associated with a particular memory-accessing instruction, and uses that structure instead of the raw MDNode* in AliasAnalysis::Location, etc. No functionality change intended. llvm-svn: 213859
* [Modules] Fix potential ODR violations by sinking the DEBUG_TYPEChandler Carruth2014-04-221-1/+2
| | | | | | | | | | definition below all the header #include lines, lib/Analysis/... edition. This one has a bit extra as there were *other* #define's before #include lines in addition to DEBUG_TYPE. I've sunk all of them as a block. llvm-svn: 206843
* [C++11] More 'nullptr' conversion. In some cases just using a boolean check ↵Craig Topper2014-04-151-14/+14
| | | | | | instead of comparing to nullptr. llvm-svn: 206243
* Replace OwningPtr<T> with std::unique_ptr<T>.Ahmed Charles2014-03-061-1/+1
| | | | | | | | | | This compiles with no changes to clang/lld/lldb with MSVC and includes overloads to various functions which are used by those projects and llvm which have OwningPtr's as parameters. This should allow out of tree projects some time to move. There are also no changes to libs/Target, which should help out of tree targets have time to move, if necessary. llvm-svn: 203083
* [Modules] Move the PredIteratorCache into the IR library -- it isChandler Carruth2014-03-041-1/+1
| | | | | | hardcoded to use IR BasicBlocks. llvm-svn: 202835
* [C++11] Replace llvm::next and llvm::prior with std::next and std::prev.Benjamin Kramer2014-03-021-1/+1
| | | | | | Remove the old functions. llvm-svn: 202636
* Make DataLayout a plain object, not a pass.Rafael Espindola2014-02-251-1/+2
| | | | | | | Instead, have a DataLayoutPass that holds one. This will allow parts of LLVM don't don't handle passes to also use DataLayout. llvm-svn: 202168
* Rename some member variables from TD to DL.Rafael Espindola2014-02-181-11/+11
| | | | | | TargetData was renamed DataLayout back in r165242. llvm-svn: 201581
* [PM] Split DominatorTree into a concrete analysis result object whichChandler Carruth2014-01-131-1/+3
| | | | | | | | | | | | | | | | | | | | | | | can be used by both the new pass manager and the old. This removes it from any of the virtual mess of the pass interfaces and lets it derive cleanly from the DominatorTreeBase<> template. In turn, tons of boilerplate interface can be nuked and it turns into a very straightforward extension of the base DominatorTree interface. The old analysis pass is now a simple wrapper. The names and style of this split should match the split between CallGraph and CallGraphWrapperPass. All of the users of DominatorTree have been updated to match using many of the same tricks as with CallGraph. The goal is that the common type remains the resulting DominatorTree rather than the pass. This will make subsequent work toward the new pass manager significantly easier. Also in numerous places things became cleaner because I switched from re-running the pass (!!! mid way through some other passes run!!!) to directly recomputing the domtree. llvm-svn: 199104
* [cleanup] Move the Dominators.h and Verifier.h headers into the IRChandler Carruth2014-01-131-1/+1
| | | | | | | | | | | | | | | | | | directory. These passes are already defined in the IR library, and it doesn't make any sense to have the headers in Analysis. Long term, I think there is going to be a much better way to divide these matters. The dominators code should be fully separated into the abstract graph algorithm and have that put in Support where it becomes obvious that evn Clang's CFGBlock's can use it. Then the verifier can manually construct dominance information from the Support-driven interface while the Analysis library can provide a pass which both caches, reconstructs, and supports a nice update API. But those are very long term, and so I don't want to leave the really confusing structure until that day arrives. llvm-svn: 199082
* Fixing a heisenbug where the memory dependence analysis behaves differentlyYunzhong Gao2013-11-141-5/+6
| | | | | | | | | | | | with and without -g. Adding a test case to make sure that the threshold used in the memory dependence analysis is respected. The test case also checks that debug intrinsics are not counted towards this threshold. Differential Revision: http://llvm-reviews.chandlerc.com/D2141 llvm-svn: 194646
* Fix xemacs mode line, don't put them in .cpp files (just header files). NoNick Lewycky2013-06-101-1/+1
| | | | | | functionality change. llvm-svn: 183709
* Use only explicit bool conversion operatorsDavid Blaikie2013-05-151-1/+1
| | | | | | | | | | | | | | | | | | | | | | | BitVector/SmallBitVector::reference::operator bool remain implicit since they model more exactly a bool, rather than something else that can be boolean tested. The most common (non-buggy) case are where such objects are used as return expressions in bool-returning functions or as boolean function arguments. In those cases I've used (& added if necessary) a named function to provide the equivalent (or sometimes negative, depending on convenient wording) test. One behavior change (YAMLParser) was made, though no test case is included as I'm not sure how to reach that code path. Essentially any comparison of llvm::yaml::document_iterators would be invalid if neither iterator was at the end. This helped uncover a couple of bugs in Clang - test cases provided for those in a separate commit along with similar changes to `operator bool` instances in Clang. llvm-svn: 181868
* Fix unchecked uses of DominatorTree in MemoryDependenceAnalysis.Matt Arsenault2013-05-061-5/+20
| | | | | | Use unknown results for places where it would be needed llvm-svn: 181176
* A limit of 500 was still a bit too high for some tests.Bill Wendling2013-04-171-3/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | PR15000 has a testcase where the time to compile was bordering on 30s. When I dropped the limit value to 100, it became a much more managable 6s. The compile time seems to increase in a roughly linear fashion based on increasing the limit value. (See the runtimes below.) So, let's lower the limit to 100 so that they can get a more reasonable compile time. Limit Value Time ----------- ---- 10 0.9744s 20 1.8035s 30 2.3618s 40 2.9814s 50 3.6988s 60 4.5486s 70 4.9314s 80 5.8012s 90 6.4246s 100 7.0852s 110 7.6634s 120 8.3553s 130 9.0552s 140 9.6820s 150 9.8804s 160 10.8901s 170 10.9855s 180 12.0114s 190 12.6816s 200 13.2754s 210 13.9942s 220 13.8097s 230 14.3272s 240 15.7753s 250 15.6673s 260 16.0541s 270 16.7625s 280 17.3823s 290 18.8213s 300 18.6120s 310 20.0333s 320 19.5165s 330 20.2505s 340 20.7068s 350 21.1833s 360 22.9216s 370 22.2152s 380 23.9390s 390 23.4609s 400 24.0426s 410 24.6410s 420 26.5208s 430 27.7155s 440 26.4142s 450 28.5646s 460 27.3494s 470 29.7255s 480 29.4646s 490 30.5001s llvm-svn: 179713
* Fix loop styleMatt Arsenault2013-03-291-2/+2
| | | | llvm-svn: 178355
* Remove 'else' after 'return'.Jakub Staszak2013-03-201-2/+4
| | | | llvm-svn: 177607
* Remove trailing spaces.Jakub Staszak2013-03-201-133/+133
| | | | llvm-svn: 177584
* Memory Dependence Analysis (not mem-dep test) take advantage of ↵Shuxin Yang2013-03-061-4/+14
| | | | | | | | | | | | | | | | "invariant.load" metadata. The "invariant.load" metadata indicates the memory unit being accessed is immutable. A load annotated with this metadata can be moved across any store. As I am not sure if it is legal to move such loads across barrier/fence, this change dose not allow such transformation. rdar://11311484 Thank Arnold for code review. llvm-svn: 176562
* Unify clang/llvm attributes for asan/tsan/msan (LLVM part)Kostya Serebryany2013-02-261-2/+2
| | | | | | | | | | | | | | | | | | | These are two related changes (one in llvm, one in clang). LLVM: - rename address_safety => sanitize_address (the enum value is the same, so we preserve binary compatibility with old bitcode) - rename thread_safety => sanitize_thread - rename no_uninitialized_checks -> sanitize_memory CLANG: - add __attribute__((no_sanitize_address)) as a synonym for __attribute__((no_address_safety_analysis)) - add __attribute__((no_sanitize_thread)) - add __attribute__((no_sanitize_memory)) for S in address thread memory If -fsanitize=S is present and __attribute__((no_sanitize_S)) is not set llvm attribute sanitize_S llvm-svn: 176075
* [tsan] disable load widening in ThreadSanitizer modeKostya Serebryany2013-02-131-0/+6
| | | | llvm-svn: 175034
* Change GetPointerBaseWithConstantOffset's DataLayout argument from aDan Gohman2013-01-311-2/+2
| | | | | | | reference to a pointer, so that it can handle the case where DataLayout is not available and behave conservatively. llvm-svn: 174024
OpenPOWER on IntegriCloud