ConstantFold: Don't optimize comparisons with weak linkage objects

Consider:
void f() {}
void __attribute__((weak)) g() {}
bool b = &f != &g;

It's possble for g to resolve to f if --defsym=g=f is passed on to the
linker.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@223585 91177308-0d34-0410-b5e6-96231b3b80d8
Reapply "LLVMContext: Store APInt/APFloat directly into the ConstantInt/FP DenseMaps."

This reapplies r223478 with a fix for 32 bit targets.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@223586 91177308-0d34-0410-b5e6-96231b3b80d8
Make the DenseMap bucket type configurable and use a smaller bucket for DenseSet.

DenseSet used to be implemented as DenseMap<Key, char>, which usually doubled
the memory footprint of the map. Now we use a compressed set so the second
element uses no memory at all. This required some surgery on DenseMap as
all accesses to the bucket now have to go through methods; this should
have no impact on the behavior of DenseMap though. The new default bucket
type for DenseMap is a slightly extended std::pair as we expose it through
DenseMap's iterator and don't want to break any existing users.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@223588 91177308-0d34-0410-b5e6-96231b3b80d8
Turn some DenseMaps that are only used for set operations into DenseSets.

DenseSet has better memory efficiency now.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@223589 91177308-0d34-0410-b5e6-96231b3b80d8
R600/SI: Add SCC Defs/Uses to SOP1 and SOP2 opcodes

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@223602 91177308-0d34-0410-b5e6-96231b3b80d8
R600/SI: Add VI instructions

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@223603 91177308-0d34-0410-b5e6-96231b3b80d8
R600/SI: Update instruction conversions for VI

There are 3 changes:
- Convert 32-bit S_LSHL/LSHR/ASHR to their V_*REV variants for VI
- Lower RSQ_CLAMP for VI
- Don't generate MIN/MAX_LEGACY on VI

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@223604 91177308-0d34-0410-b5e6-96231b3b80d8
[x86] Clean up the shift lowering vector shuffle tests a bit using my
script. Notably this folds all the SSE cases together into a single
FileCheck block. It also adds a vex prefix.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@223610 91177308-0d34-0410-b5e6-96231b3b80d8
[x86] Cleanup the combining vector shuffle tests a bit by merging
identical checks for different SSE variants into a single block.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@223611 91177308-0d34-0410-b5e6-96231b3b80d8
[x86] Switch a constant selection test to use positive assertions and to
store to real pointers so that its clear that the right code is in fact
being generated.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@223612 91177308-0d34-0410-b5e6-96231b3b80d8
[x86] Clean up the SSE1 test to use a slightly different pattern for
matching offsets. I don't expect this to really matter, but its what the
latest incarnation of my script for maintaining these tests happens to
produce, and so its simpler for me if everything matches.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@223613 91177308-0d34-0410-b5e6-96231b3b80d8
R600/SI: Set 20-bit immediate byte offset for SMRD on VI

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@223614 91177308-0d34-0410-b5e6-96231b3b80d8
R600/SI: Disable VMEM and SMEM clauses by breaking them with S_NOP

This is only a workaround.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@223615 91177308-0d34-0410-b5e6-96231b3b80d8
IR: Add missing tests for function-local metadata

Add assembly and bitcode tests that I neglected to add in r223564 (IR:
Disallow complicated function-local metadata) and r223574 (IR: Disallow
function-local metadata attachments).

Found a couple of bugs:

  - The error message for function-local attachments gave the wrong line
    number -- it indicated the next token (typically on the next line)
    instead of the token that started the attachment.  Fixed.

  - Metadata arguments of the form `!{i32 0, i32 %v}` (or with the
    arguments reversed) fired an assertion in `ValueEnumerator` in LLVM
    v3.5, so I suppose this never really worked.  I suppose this was
    "fixed" by r223564.

(Thanks to dblaikie for pointing out my omission.)

Part of PR21532.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@223616 91177308-0d34-0410-b5e6-96231b3b80d8
IR: Remove reference to ENABLE_MDNODE_UNIQUING

Apparently `MDNode` uniquing used to be optional.  I suppose the
configure flag must have disappeared at some point.  Change the test so
it actually tests uniquing, and remove the check for
`ENABLE_MDNODE_UNIQUING`.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@223617 91177308-0d34-0410-b5e6-96231b3b80d8
IR: Drop uniquing for self-referencing MDNodes

It doesn't make sense to unique self-referencing nodes.  Drop uniquing
for them.

Note that `MDNode::intersect()` occasionally returns self-referencing
nodes.  Previously these would be returned by `MDNode::get()`.  I'm not
convinced this was intended behaviour -- to me it seems it should return
a node whose only operand is the self-reference -- but I don't know much
about alias scopes so I'm preserving it for now.

This is part of PR21532.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@223618 91177308-0d34-0410-b5e6-96231b3b80d8
IR: Revert r223618 behaviour of MDNode::concatenate()

r223618 including special handling of `MDNode::intersect()`: if the
first operand is a self-reference with the same operands you're trying
to return, return it instead.

Reuse that handling in `MDNode::concatenate()` in the hopes that it
fixes a polly test that seems to rely on the old behaviour [1].

[1]: http://lab.llvm.org:8011/builders/polly-amd64-linux/builds/25167

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@223619 91177308-0d34-0410-b5e6-96231b3b80d8
IR: Fix bitcode compatability filenames

As a fixup to r223616, follow the convention of naming the files after
the LLVM release whose bitcode they're maintaining compatability with.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@223623 91177308-0d34-0410-b5e6-96231b3b80d8
Revert a part of r223583, for now. It seems causing different emission between stage2(gcc-clang) and stage3 clang. Investigating.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@223624 91177308-0d34-0410-b5e6-96231b3b80d8