Avoid creating a new `ConstantVector` on an RAUW of one of its members.
This reduces RAUW traffic on any containing constant.

This is part of PR20515.

llvm-svn: 215966

Previously, `ConstantArray::replaceUsesOfWithOnConstant()` neglected to
check whether it becomes a `ConstantDataArray`.  Call
`ConstantArray::getImpl()` to check for that.

llvm-svn: 215965

Factor out common code, and take advantage of the new function to
add early returns to the callers.

llvm-svn: 215964

Introduce `getImpl()` that tries the simplification logic from `get()`
and then gives up.  This allows the logic to be reused elsewhere in a
follow-up commit.

llvm-svn: 215963

<rdar://problem/16952634>

llvm-svn: 215962

DFSan's set label function should avoid writing to the shadow memory when the write would not change the value in memory.

When writing a label to shadow memory, don't write if the value is already set to the value being written.  This dramatically reduces real memory consumption in programs with sparse use of labels.

Test Plan: It would be nice to test that unnecessary writes are skipped, but I do not see how a unit test could do this.

Patch by Sam Kerner!

Differential Revision: http://reviews.llvm.org/D4894

llvm-svn: 215961

Avoid RAUW-ing `ConstantExpr` when an operand changes unless the new
`ConstantExpr` already has users.  This prevents the RAUW from rippling
up the expression tree unnecessarily.

This commit indirectly adds test coverage for r215953 (this is how I
came across the bug).

This is part of PR20515.

llvm-svn: 215960

Now that `ConstantAggrUniqueMap` and `ConstantUniqueMap` work the same
way, change the aggregates to use the new one.

llvm-svn: 215959

llvm-svn: 215958

Rewrite `ConstantUniqueMap` to be more similar to
`ConstantAggrUniqueMap`.

  - Use a `DenseMap` with custom MapInfo instead of a `std::map` with
    linear lookups and deletion.
  - Don't waste memory explicitly storing (heavyweight) keys.

Only `ConstantExpr` and `InlineAsm` actually use this data structure, so
I also updated them to use it.

This code cleanup is a precursor to reducing RAUW traffic on
`ConstantExpr` -- I felt badly adding a new (linear) call to
`ConstantUniqueMap::FindExistingKey`, so this designs away the concern.

A follow-up commit will transition the users of `ConstantAggrUniqueMap`
over.

llvm-svn: 215957

llvm-svn: 215956

No functionality change.

llvm-svn: 215955

llvm-svn: 215954

This code had a homemade RAUW that was incorrect when a user was a
constant: instead of calling `replaceUsersWithOnConstant()` it would
incorrectly update the operand in-place, invalidating
`LLVMContextImpl::ExprConstants`.  RAUW does the job better.

The ValueHandle that `GVMap` is holding onto needs to be removed first,
so this commit also removes each variable from the map on-the-fly.

Since deletions from `ExprConstants` use a linear search that compares
directly on the pointer value (instead of using the key), there isn't an
obvious way to expose this with a testcase.

llvm-svn: 215953

Previously all `blockaddress()` constants were treated as forward
references.  They were resolved twice:  once at the end of the function
in question, and again at the end of the module.  Furthermore, if the
same blockaddress was referenced N times, the parser created N distinct
`GlobalVariable`s (one for each reference).

Instead, resolve all block addresses at the beginning of the function,
creating the standard `BasicBlock` forward references used for all other
basic block references.  After the function, all references can be
resolved immediately.  To check for the condition of parsing block
addresses from within the same function, I created a reference to the
current per-function-state in `BlockAddressPFS`.

Also, create only one forward-reference per basic block.  Because
forward references to block addresses are rare, the data structure here
shouldn't matter.  If somehow it does someday, this can be pretty easily
changed to a `DenseMap<std::pair<ValID, ValID>, GV>`.

This is part of PR20515.

llvm-svn: 215952

Call `verifyModule()` after parsing and after every transformation.
Also convert some `DEBUG(dbgs())` to `errs()` to increase visibility
into what's going on.

llvm-svn: 215951

Patch by Ismail Donmez
http://reviews.llvm.org/D4953

llvm-svn: 215950

another sanitizer.

A user may run both LSan and LSan+ASan. It is weird to pass path to leak
suppression file (or other common sanitizer flags, like "verbosity") in
"LSAN_OPTIONS" in the first case and in "ASAN_OPTIONS" in the second case.

llvm-svn: 215949

llvm-svn: 215948

The commit broke public build bots for more than 24 hours.

(view as text)
******************** TEST 'Clang Tools :: clang-rename/VarTest.cpp' FAILED ********************
Script:
--
cat /Users/buildslave/zorg/buildbot/smooshlab/slave-0.8/build.clang-x86_64-darwin11-nobootstrap-RAincremental/clang.src/tools/extra/test/clang-rename/VarTest.cpp > /Users/buildslave/zorg/buildbot/smooshlab/slave-0.8/build.clang-x86_64-darwin11-nobootstrap-RAincremental/clang-build/tools/clang/tools/extra/test/clang-rename/Output/VarTest.cpp.tmp.cpp
clang-rename -offset=$(grep -FUbo 'foo;' /Users/buildslave/zorg/buildbot/smooshlab/slave-0.8/build.clang-x86_64-darwin11-nobootstrap-RAincremental/clang-build/tools/clang/tools/extra/test/clang-rename/Output/VarTest.cpp.tmp.cpp | head -1 | cut -d: -f1) -new-name=hector /Users/buildslave/zorg/buildbot/smooshlab/slave-0.8/build.clang-x86_64-darwin11-nobootstrap-RAincremental/clang-build/tools/clang/tools/extra/test/clang-rename/Output/VarTest.cpp.tmp.cpp -i --
sed 's,//.*,,' /Users/buildslave/zorg/buildbot/smooshlab/slave-0.8/build.clang-x86_64-darwin11-nobootstrap-RAincremental/clang-build/tools/clang/tools/extra/test/clang-rename/Output/VarTest.cpp.tmp.cpp | FileCheck /Users/buildslave/zorg/buildbot/smooshlab/slave-0.8/build.clang-x86_64-darwin11-nobootstrap-RAincremental/clang.src/tools/extra/test/clang-rename/VarTest.cpp
--
Exit Code: 1

Command Output (stderr):
--
clang-rename: could not find symbol at /Users/buildslave/zorg/buildbot/smooshlab/slave-0.8/build.clang-x86_64-darwin11-nobootstrap-RAincremental/clang-build/tools/clang/tools/extra/test/clang-rename/Output/VarTest.cpp.tmp.cpp:2:1 (offset 14).

llvm-svn: 215947

One more, and the number of flags without a dedicated flag fits in two decimal
digits :-)

llvm-svn: 215946

llvm-svn: 215945

llvm-svn: 215944

- 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

Monotonic accesses do not have to kill the analysis, as long as the QueryInstr is not
itself atomic.

llvm-svn: 215942

llvm-svn: 215941

1. Always put static sanitizer runtimes to the front of the linker
invocation line. This was already done for all sanitizers except UBSan:
in case user provides static libstdc++ we need to make sure that new/delete
operator definitions are picked from sanitizer runtimes instead of libstdc++.
We have to put UBSan runtime first for similar reasons: it depends on some
libstdc++ parts (e.g. __dynamic_cast function), and has to go first in
link line to ensure these functions will be picked up from libstdc++.

2. Put sanitizer libraries system dependencies (-ldl, -lpthread etc.) right
after sanitizer runtimes. This will ensure these libraries participate in
the link even if user provided -Wl,-as-needed flag. This should fix PR15823.

3. In case we link in several sanitizer runtimes (e.g. "ubsan", "ubsan_cxx"
and "san"), add system dependencies (-ldl, -lpthread, ...) only once.

llvm-svn: 215940

llvm-svn: 215939

This patch may address some of the issues described in http://llvm.org/PR20640.

llvm-svn: 215938

Cleanup how we listen for process events by using the broadcaster class name instead of having to catch each process instance as it comes alive.

llvm-svn: 215937

llvm-svn: 215936

llvm-svn: 215935

llvm-svn: 215934

llvm-svn: 215933

llvm-svn: 215932

file with -macho, the Mach-O specific object file parser option.

After some discussion I chose to do this implementation contained in the logic
of llvm-objdump’s MachODump.cpp using a second disassembler for thumb when
needed and with updates mostly contained in the MachOObjectFile class.

llvm-svn: 215931

This is still needed for VS2012.

llvm-svn: 215930

Predefined decls like 'Protocol' in objc are not loaded from AST files,
so we cannot rely on loading the canonical decl to complete the redecl
chain for redeclarations of these decls.  The broken redecl chain was
non-circular, so looping over redecls() would hang.

llvm-svn: 215929

llvm-svn: 215928

llvm-svn: 215927