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

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

llvm-svn: 215948

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

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

llvm-svn: 215938

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

<rdar://problem/15607571>

llvm-svn: 215924

Group: Floating Point XMM and YMM instructions.
Sub-group: Other instructions.

<rdar://problem/15607571>

llvm-svn: 215923

Group: Floating Point XMM and YMM instructions.
Sub-group: Logic instructions.

<rdar://problem/15607571>

llvm-svn: 215922

Group: Floating Point XMM and YMM instructions.
Sub-group: Math instructions.

<rdar://problem/15607571>

llvm-svn: 215921

Group: Floating Point XMM and YMM instructions.
Sub-group: Arithmetic instructions.

<rdar://problem/15607571>

llvm-svn: 215920

Group: Floating Point XMM and YMM instructions.
Sub-group: Conversion instructions.

<rdar://problem/15607571>

llvm-svn: 215919

Group: Floating Point XMM and YMM instructions.
Sub-group: Move instructions.

<rdar://problem/15607571>

llvm-svn: 215918

Group: Integer MMX and XMM instructions.
Sub-group: Other instructions.

<rdar://problem/15607571>

llvm-svn: 215917

Group: Integer MMX and XMM instructions.
Sub-group: Logic instructions.

<rdar://problem/15607571>

llvm-svn: 215916

Group: Integer MMX and XMM instructions.
Sub-group: Arithmetic instructions.

<rdar://problem/15607571>

llvm-svn: 215915

Group: Integer MMX and XMM instructions.
Sub-group: Move instructions.

<rdar://problem/15607571>

llvm-svn: 215914

Group: Floating Point x87 instructions.
Sub-group: Math instructions.

<rdar://problem/15607571>

llvm-svn: 215913

Group: Floating Point x87 instructions.
Sub-group: Arithmetic instructions.

<rdar://problem/15607571>

llvm-svn: 215912

Group: Floating Point x87 instructions.
Sub-group: Move instructions.

<rdar://problem/15607571>

llvm-svn: 215911

Group: Integer instructions.
Sub-group: Other instructions.

<rdar://problem/15607571>

llvm-svn: 215910

Group: Integer instructions.
Sub-group: Synchronization instructions.

<rdar://problem/15607571>

llvm-svn: 215909

Group: Integer instructions.
Sub-group: String instructions.

<rdar://problem/15607571>

llvm-svn: 215908

Group: Integer instructions.
Sub-group: Control transfer instructions.

<rdar://problem/15607571>

llvm-svn: 215907