InstSimplify: X >> X -> 0


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@185973 91177308-0d34-0410-b5e6-96231b3b80d8
Rename BlackList class to SpecialCaseList and move it to Transforms/Utils.

Differential Revision: http://llvm-reviews.chandlerc.com/D1089

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@185975 91177308-0d34-0410-b5e6-96231b3b80d8
Introduce a SpecialCaseList ctor which takes a MemoryBuffer to make
it more unit testable, and fix memory leak in the other ctor.

Differential Revision: http://llvm-reviews.chandlerc.com/D1090

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@185976 91177308-0d34-0410-b5e6-96231b3b80d8
Add some SpecialCaseList unit tests.

Differential Revision: http://llvm-reviews.chandlerc.com/D1091

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@185977 91177308-0d34-0410-b5e6-96231b3b80d8
Implement categories for special case lists.

A special case list can now specify categories for specific globals,
which can be used to instruct an instrumentation pass to treat certain
functions or global variables in a specific way, such as by omitting
certain aspects of instrumentation while keeping others, or informing
the instrumentation pass that a specific uninstrumentable function
has certain semantics, thus allowing the pass to instrument callers
according to those semantics.

For example, AddressSanitizer now uses the "init" category instead of
global-init prefixes for globals whose initializers should not be
instrumented, but which in all other respects should be instrumented.

The motivating use case is DataFlowSanitizer, which will have a
number of different categories for uninstrumentable functions, such
as "functional" which specifies that a function has pure functional
semantics, or "discard" which indicates that a function's return
value should not be labelled.

Differential Revision: http://llvm-reviews.chandlerc.com/D1092

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@185978 91177308-0d34-0410-b5e6-96231b3b80d8
ARM: Fix incorrect pack pattern for thumb2

Propagate the fix from r185712 to Thumb2 codegen as well. Original
commit message applies here as well:

A "pkhtb x, x, y asr #num" uses the lower 16 bits of "y asr #num" and
packs them in the bottom half of "x". An arithmetic and logic shift are
only equivalent in this context if the shift amount is 16. We would be
shifting in ones into the bottom 16bits instead of zeros if "y" is
negative.

rdar://14338767

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

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


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@185987 91177308-0d34-0410-b5e6-96231b3b80d8
Document a known limitation of the status quo.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@185992 91177308-0d34-0410-b5e6-96231b3b80d8
Un-break the buildbot by tweaking the indirection flag.
Pulled in a testcase from the debuginfo-test suite.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@185993 91177308-0d34-0410-b5e6-96231b3b80d8
Explicitly define ARMISelLowering::isFMAFasterThanFMulAndFAdd. No functionality change.

Currently ARM is the only backend that supports FMA instructions (for at least some subtargets) but does not implement this virtual, so FMAs are never generated except from explicit fma intrinsic calls. Apparently this is due to the fact that it supports both fused (one rounding step) and unfused (two rounding step) multiply + add instructions. This patch clarifies that this the case without changing behavior by implementing the virtual function to simply return false, as the default TargetLoweringBase version does.

It is possible that some cpus perform the fused version faster than the unfused version and vice-versa, so the function implementation should be revisited if hard data is found.


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


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