[XCore] Provide information about known zero bits of resource instructions.

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

[asan] fix a pair of silly typos

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

[asan] disable asan-detect-invalid-pointer-pair (was enabled by mistake)

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

[asan] *experimental* implementation of invalid-pointer-pair detector (finds when two unrelated pointers are compared or subtracted). This implementation has both false positives and false negatives and is not tuned for performance. A bug report for a proper implementation will follow.

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

[docs] Actually spell out the new version requirements for the host C++
toolchain of LLVM. These are already being enforced by the build system
and have been discussed quite a few times on the lists, but
documentation is important. =]

Also, garbage collect the majority of the information about broken host
GCC toolchains. These aren't really relevant any more as they're all
older than the minimum requirement. I've left a few notes about
compilers one step older than the current requirement as these compilers
are at least conceivable to use, and it's better to preserve this kind
of hard-won institutional knowledge.

The next step will be some specific docs on how to set up a sufficiently
modern host toolchain if your system doesn't come with one. But that'll
be tomorrow. =]

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

[docs] Clean up some of the required software to not mention irrelevant
bits of software and to use a modern GCC version.

The Subversion bit was weird anyways -- it has nothing to do with
compiling LLVM. Also, there are many other ways to get at the trunk
source (git, git-svn, etc).

The TeXinfo thing... I have no idea about. But you can get a working
LLVM w/o it pretty easily. If man pages or something are missing, that
hardly seems like a problem. If folks really want this back, let me
know, but it seems mostly like a distraction.

I'd still like to separate this into:
- Required software to compile.
- Optional software to compile.
- Required software for certain *contributor* activities (like
  regenerating configure scripts).

Also we need to mention that there are multiple options for build
systems, and the differences.

Also we should mention Windows.

Also probably other stuff I'm forgetting.

I'm wondering if this whole thing needs to be shot in the head and we
should just start a new, simpler getting started that doesn't have so
many years of accumulated stuff that is no longer relevant.

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

[docs] Switch this table to the simple form as well. No content changed.

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

[docs] Switch to the incredibly simpler "simple table" form. It now
actually looks like the table on the webpage and is entertainingly
smaller, easier to read, and easier to edit.

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

[docs] Delete tons of bad information in the requirements section of the
getting started guide.

Some highlights:
- I heard there was this Clang compiler that you could use for your
  host compiler. Not sure though.
- We no longer have a GCC frontend with weird build restrictions.
- Windows is doing a bit better than partially supported.
- We nuked everything to do with itanium.
- SPUs? Really?
- Xcode 2.5 and gcc 4.0.1 are really not a concern -- they don't work.
- OMG, we actually tried building LLVM on Alpha? Really?
- PowerPC works pretty well these days.

There is still a lot of stuff here I'm pretty dubious about, but I nuked
most of what was actively misleading, out of date, or patently wrong.
Some of it (mingw stuff especially) isn't really lacking, its just that
the comments here were actively wrong. Hopefully folks that know those
platforms can add back correct / modern information.

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

Stop test/CodeGen/X86/v4i32load-crash.ll targeting non-X86-64 targets.

Summary:
Fixes an issue where a test attempts to use -mcpu=x86-64 on non-X86-64 targets.
This triggers an assertion in the MIPS backend since it doesn't know what ABI to
use by default for unrecognized processors.

CC: llvm-commits, rafael
Differential Revision: http://llvm-reviews.chandlerc.com/D2877

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

[CMake] Introduce LLVM_BUILD_EXTERNAL_COMPILER_RT option

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

Don't emit anything into the debug_ranges section if we aren't emitting
any ranges - this includes CU ranges where we were previously emitting an
end list marker even if we didn't have a list.

Testcase includes a test for line table only code emission as the problem
was noticed while writing this test.

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

Exception handling docs: Fix a typo

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

[X86] Fix Uses/Defs lists for INS, OUTS, SCAS, CMPS, LODS

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

[X86] Add RAX/EAX/AX Uses/Defs to XCHG RAX/EAX/AX instructions.

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

[X86] Add RAX/EAX/AX/AL Uses/Defs to the absolute memory location move instructions. Patch by Florian Lukas with some additional instructions fixed by me. Fixes PR18975.

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

Fix indentation.

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

Fix odd indentation.

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

Revert "Use count 0."

This reverts commit r202283, because when we use GuardMalloc the test will fail
due to additional output to std err.

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

Revert "Use StringRef in raw_fd_ostream constructor"

This reverts commit r202225, which may cause a performance regression.

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

R600/SI: Optimize SI_KILL for constant operands

If the SI_KILL operand is constant, we can either clear the exec mask if
the operand is negative, or do nothing otherwise.

Reviewed-by: Tom Stellard <thomas.stellard@amd.com>
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@202337 91177308-0d34-0410-b5e6-96231b3b80d8

R600/SI: Allow SI_KILL for geometry shaders

Reviewed-by: Tom Stellard <thomas.stellard@amd.com>
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@202336 91177308-0d34-0410-b5e6-96231b3b80d8

If we're only emitting line tables for a particular CU then don't add
any ranges to the list of ranges for the CU as we don't want to emit
them anyway. This ensures that we will still emit ranges if we have
a compile unit compiled with only line tables and one compiled with
full debug info requested (we'll emit for the one with full debug info).

Update testcase metadata accordingly to continue emitting ranges.

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

Add a debug info code generation level to the compile unit metadata
and update everything accordingly. This can be used to conditionalize
the amount of output in the backend based on the amount of debug
requested/metadata emission scheme by a front end (e.g. clang).

Paired with a commit to clang.

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

Formatting.

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

Add an explanatory comment.

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

Grammar and spelling.

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

Fix a type error that crept into r202313.

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

Remove unnecessary llvm:: qualification.

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

Use regnum regex in an XCore test case.

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

Debug info: Refactor AsmPrinter::EmitDwarfRegOp to make the control flow
more obvious.

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

R600: Remove unnecessary build_vector pattern.

It is already fully handled in AMDGPUISelDAGToDAG.

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

Very temporarily XFAILing a test. Will be fixed shortly.

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

Fix broken FileCheck prefixes

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

Add a limit to the heuristic that register allocates instructions in local order.

This handles pathological cases in which we see 2x increase in spill
code for large blocks (~50k instructions). I don't have a unit test
for this behavior.

Fixes rdar://16072279.

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

Use an install name dir of @executable_path/../lib instead of @rpath.

Using @executable_path/../lib matches what we have on Makefiles and works
with older versions of OS X too.

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

Lower unsigned vsetcc to psubus in certain cases

The current approach to lower a vsetult is to flip the sign bit of the
operands, swap the operands and then use a (signed) pcmpgt.  psubus (unsigned
saturating subtract) can be used to emulate a vsetult more efficiently:

+    case ISD::SETULT: {
+      // If the comparison is against a constant we can turn this into a
+      // setule.  With psubus, setule does not require a swap.  This is
+      // beneficial because the constant in the register is no longer
+      // destructed as the destination so it can be hoisted out of a loop.

I also enable lowering via psubus in a few other cases where it's clearly
beneficial: setule and setuge if minu/maxu cannot be used.

rdar://problem/14338765

Patch by Adam Nemet <anemet@apple.com>.

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

Don't mix the plain and keyword signatures of target_link_libraries.

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

Silencing an MSVC signed comparison warning.

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

Fix the aggressive anti-dep breaker's subregister definition handling

The aggressive anti-dependency breaker scans instructions, bottom-up, within the
scheduling region in order to find opportunities where register renaming can
be used to break anti-dependencies.

Unfortunately, the aggressive anti-dep breaker was treating a register definition
as defining all of that register's aliases (including super registers). This behavior
is incorrect when the super register is live and there are other definitions of
subregisters of the super register.

For example, given the following sequence:

%CR2EQ<def> = CROR %CR3UN, %CR3UN<kill>
%CR2GT<def> = IMPLICIT_DEF
%X4<def> = MFOCRF8 %CR2

the analysis of the first subregister definition would work as expected:
Anti:   %CR2GT<def> = IMPLICIT_DEF
        Def Groups: CR2GT=g194->g0(via CR2)
        Antidep reg: CR2GT (zero group)
        Use Groups:

but the analysis of the second one would not:
Anti:   %CR2EQ<def> = CROR %CR3UN, %CR3UN<kill>
        Def Groups: CR2EQ=g195
        Antidep reg: CR2EQ
        Rename Candidates for Group g195: ...

because, when processing the %CR2GT<def>, we'd mark all super registers of
%CR2GT (%CR2 in this case) as defined. As a result, when processing
%CR2EQ<def>, %CR2 no longer appears to be live, and %CR2EQ<def>'s group is not
%unioned with the %CR2 group.

I don't have an in-tree test case for this yet (and even if I did, I don't have
a small one).

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

GlobalOpt: Apply fastcc to internal x86_thiscallcc functions

We should apply fastcc whenever profitable.  We can expand this list,
but there are lots of conventions with performance implications that we
don't want to change.

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

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

Relax COFF string table check

COFF object files with 0 as string table size are currently rejected. This
prevents us from reading object files written by tools like cvtres that
violate the PECOFF spec and write 0 instead of 4 for the size of an empty
string table.

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

Fix broken FileCheck prefix

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

Use the overloaded std::abs rather than C's abs(int) to address Clang's -Wabsolute-value

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

Use count 0.

Thanks to Roman Divacky for the suggestion.

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

Fix typo. Thanks to Roman Divacky for noticing it.

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

Compare DataLayout by Value, not by pointer.

This fixes spurious warnings in llvm-link about the datalayout not matching.

Thanks to Zalman Stern for reporting the bug!

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

Use a sorted array to store the information about a few address spaces.

We don't have any test with more than 6 address spaces, so a DenseMap is
probably not the correct answer.

An unsorted array would also be OK, but we have to sort it for printing anyway.

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

Move these functions out of line. A DenseMap lookup is not a simple operation.

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

Fix PR18165: LSR must avoid scaling factors that exceed the limit on truncated use.

Patch by Michael Zolotukhin!

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

llvm-symbolizer: use dynamic symbol table if the regular one is stripped.

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

Move getELFDynamicSymbolIterators to a public header.

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

[CMake] BUILD_SHARED_LIBS: Fixup for r202261: Give PULIC to system_libs in LLVMSupport.

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

Ensure bitcode encoding of instructions and their operands stays stable.
This includes instructions with aggregate operands (insert/extract), instructions with vector operands (insert/extract/shuffle), binary arithmetic and bitwise instructions, conversion instructions and terminators.

Work was done by lama.saba@intel.com.

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

[CMake] Work around to use target_link_libraries(PUBLIC) in BUILD_SHARED_LIBS mode.

FIXME: It may be PRIVATE since SO knows its dependent libs.

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

[CMake] Move LLVMBUILD_LIB_DEPS stuff from add_llvm_library (and LLVm-Config) to llvm_add_library to centralize target_link_libraries.

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

AArch64: simplify tbl/tbx polymorphism

The table argument is always 128-bit (and interpreted as <16 x i8>) so the
extra specifier for it is just clutter.

No user-visible behaviour change, so no tests.

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

ARMv8 IfConversion must skip narrow instructions that a) define CPSR and b) wouldn't affect CPSR in an IT block

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

Stop test/CodeGen/ARM/a15.ll targetting non-ARM targets.

Summary:
Fixes an issue where a test attempts to use -mcpu=cortex-a15 on non-ARM targets.
This triggers an assertion on MIPS since it doesn't know what ABI to use by default for
unrecognized processors.

Reviewers: rengolin

Reviewed By: rengolin

CC: llvm-commits, aemerson, rengolin
Differential Revision: http://llvm-reviews.chandlerc.com/D2876

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

[mips] Treat -mcpu=generic the same way as an empty CPU string.

Summary:
This should fix the MCJIT unit tests that were broken by r201792 on the MIPS buildbot.
MIPS currently uses the default implementation of sys::getHostCPUName() which
always returns "generic". For now, we will accept "generic" and coerce it to
"mips32" or "mips64" depending on the target architecture like we do for empty
CPU names.

Reviewers: jacksprat, matheusalmeida

Reviewed By: jacksprat

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

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

[SROA] Use the correct index integer size in GEPs through non-default
address spaces.

This isn't really a correctness issue (the values are truncated) but its
much cleaner.

Patch by Matt Arsenault!

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

Add two helpers to IRBuilder to flesh the interface out to N-width
integers. Complements the interfaces it is wrapping.

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

[SROA] Teach SROA how to handle pointers from address spaces other than
the default.

Based on the patch by Matt Arsenault, D1764!

I switched one place to use the more direct pointer type to compute the
desired address space, and I reworked the memcpy rewriting section to
reflect significant refactorings that this patch helped inspire.

Thanks to several of the folks who helped review and improve the patch
as well.

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

[SROA] Split the alignment computation complete for the memcpy rewriting
to work independently for the slice side and the other side.

This allows us to only compute the minimum of the two when we actually
rewrite to a memcpy that needs to take the minimum, and preserve higher
alignment for one side or the other when rewriting to loads and stores.

This fix was inspired by seeing the result of some refactoring that
makes addrspace handling better.

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

[CMake] Use target_link_libraries(INTERFACE|PRIVATE) on CMake-2.8.12 to increase opportunity for parallel build.

target_link_libraries(INTERFACE) doesn't bring inter-target dependencies in add_library,
although final targets have dependencies to whole dependent libraries.
It makes most libraries can be built in parallel.

target_link_libraries(PRIVATE) is used to shaared library.
Each dependent library is linked to the target.so, and its user will not see its grandchildren.
For example,

  - libclang.so has sufficient libclang*.a(s).
  - c-index-test requires just only libclang.so.

FIXME: lld is tweaked minimally. Adding INTERFACE in each library would be better thing.

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

[x86] Add same itinerary to SYSEXIT64 as SYSEXIT for consistency.

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

[CMake] Introduce cmake_policy(CMP0022) for target_link_libraries(INTERFACE|PRIVATE).

For now, use both keywords, INTERFACE and PRIVATE via the variable,
  - ${cmake_2_8_12_INTERFACE}
  - ${cmake_2_8_12_PRIVATE}

They could be cleaned up when we introduce 2.8.12.

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

[CMake] Use LINK_LIBS instead of target_link_libraries().

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

[x86] Remove some unused instruction format classes.

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

[x86] Simplify disassembler code slightly.

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

[SROA] The original refactoring inspired by the addrspace patch in
D1764, which in turn set off the other refactorings to make
'getSliceAlign()' a sensible thing.

There are two possible inputs to the required alignment of a memory
transfer intrinsic: the alignment constraints of the source and the
destination. If we are *only* introducing a (potentially new) offset
onto one side of the transfer, we don't need to consider the alignment
constraints of the other side. Use this to simplify the logic feeding
into alignment computation for unsplit transfers.

Also, hoist the clamp of the magical zero alignment for these intrinsics
to the more customary one alignment early. This lets several other
conditions melt away.

No functionality changed. There is a further improvement this exposes
which *will* change functionality, but that's arriving in a separate
patch.

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

[SROA] Yet another slight refactoring that simplifies an API in the
rewriting logic: don't pass custom offsets for the adjusted pointer to
the new alloca.

We always passed NewBeginOffset here. Sometimes we spelled it
BeginOffset, but only when they were in fact equal. Whats worse, the API
is set up so that you can't reasonably call it with anything else -- it
assumes that you're passing it an offset relative to the *original*
alloca that happens to fall within the new one. That's the whole point
of NewBeginOffset, it's the clamped beginning offset.

No functionality changed.

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

[SROA] Simplify the computing of alignment: we only ever need the
alignment of the slice being rewritten, not any arbitrary offset.

Every caller is really just trying to compute the alignment for the
whole slice, never for some arbitrary alignment. They are also just
passing a type when they have one to see if we can skip an explicit
alignment in the IR by using the type's alignment. This makes for a much
simpler interface.

Another refactoring inspired by the addrspace patch for SROA, although
only loosely related.

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

[SROA] Use NewOffsetBegin in the unsplit case for memset merely for
consistency with memcpy rewriting, and fix a latent bug in the alignment
management for memset.

The alignment issue is that getAdjustedAllocaPtr is computing the
*relative* offset into the new alloca, but the alignment isn't being set
to the relative offset, it was using the the absolute offset which is
into the old alloca.

I don't think its possible to write a test case that actually reaches
this code where the resulting alignment would be observably different,
but the intent was clearly to use the relative offset within the new
alloca.

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

[SROA] Use the members for New{Begin,End}Offset in the rewrite helpers
rather than passing them as arguments.

While I generally prefer actual arguments, in this case the readability
loss is substantial. By using members we avoid repeatedly calculating
the offsets, and once we're using members it is useful to ensure that
those names *always* refer to the original-alloca-relative new offset
for a rewritten slice.

No functionality changed. Follow-up refactoring, all toward getting the
address space patch merged.

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

[SROA] Compute the New{Begin,End}Offset values once for each alloca
slice being rewritten.

We had the same code scattered across most of the visits. Instead,
compute the new offsets and the slice size once when we start to visit
a particular slice, and use the member variables from then on. This
reduces quite a bit of code duplication.

No functionality changed. Refactoring inspired to make it easier to
apply the address space patch to SROA.

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

Use StringRef in raw_fd_ostream constructor

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

[SROA] Fix PR18615 with some long overdue simplifications to the bounds
checking in SROA.

The primary change is to just rely on uge for checking that the offset
is within the allocation size. This removes the explicit checks against
isNegative which were terribly error prone (including the reversed logic
that led to PR18615) and prevented us from supporting stack allocations
larger than half the address space.... Ok, so maybe the latter isn't
*common* but it's a silly restriction to have.

Also, we used to try to support a PHI node which loaded from before the
start of the allocation if any of the loaded bytes were within the
allocation. This doesn't make any sense, we have never really supported
loading or storing *before* the allocation starts. The simplified logic
just doesn't care.

We continue to allow loading past the end of the allocation in part to
support cases where there is a PHI and some loads are larger than others
and the larger ones reach past the end of the allocation. We could solve
this a different and more conservative way, but I'm still somewhat
paranoid about this.

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

Remove spurious emacs major mode marker, these should only go on .h files.

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

80-col.

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

Formatting fixups.

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

Delete two declared overloads of CallInst::CallInst that are never defined or used. No functionality change.

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

Constify the Optnone checks in IR passes.

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

Simplify base64 routine a bit.

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

Exception handling docs: Describe landingpad clauses' meanings in more detail

The original text is very terse, so I've expanded on it.

Specifically, in the original text:

 * "The selector value is a positive number if the exception matched a
   type info" -- It wasn't clear that this meant "if the exception
   matched a 'catch' clause".

 * "If nothing is matched, the behavior of the program is
   `undefined`_."  -- It's actually implementation-defined in C++
   rather than undefined, as the new text explains.

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

Add DIUnspecifiedParameter, so we can pretty-print it.
This will be used for testcases in CFE.

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

fix crash in SmallDenseMap copy constructor

Prevent a crash in the SmallDenseMap copy constructor whenever the other
map is not in small mode.

<rdar://problem/14292693>

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

Use DataLayout from the module when easily available.

Eventually DataLayoutPass should go away, but for now that is the only easy
way to get a DataLayout in some APIs. This patch only changes the ones that
have easy access to a Module.

One interesting issue with sometimes using DataLayoutPass and sometimes
fetching it from the Module is that we have to make sure they are equivalent.
We can get most of the way there by always constructing the pass with a Module.
In fact, the pass could be changed to point to an external DataLayout instead
of owning one to make this stricter.

Unfortunately, the C api passes a DataLayout, so it has to be up to the caller
to make sure the pass and the module are in sync.

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

Attempt to unbreak an MSVC buildbot by switching to %llc_dwarf.

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

DwarfDebug: Avoid emitting an empty debug_aranges section when aranges are disabled

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

Address review comments for r202188.
This is refactoring / simplifying code, updating comments and enabling the
testcase on non-x86 platforms.

No functionality change.

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

Fix resetting the DataLayout in a Module.

No tool does this currently, but as everything else in a module we should be
able to change its DataLayout.

Most of the fix is in DataLayout to make sure it can be reset properly.

The test uses Module::setDataLayout since the fact that we mutate a DataLayout
is an implementation detail. The module could hold a OwningPtr<DataLayout> and
the DataLayout itself could be immutable.

Thanks to Philip Reames for pushing me in the right direction.

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

[reassociate] Switch two std::sort calls into std::stable_sort calls as
their inputs come from std::stable_sort and they are not total orders.

I'm not a huge fan of this, but the really bad std::stable_sort is right
at the beginning of Reassociate. After we commit to stable-sort based
consistent respect of source order, the downstream sorts shouldn't undo
that unless they have a total order or they are used in an
order-insensitive way. Neither appears to be true for these cases.
I don't have particularly good test cases, but this jumped out by
inspection when looking for output instability in this pass due to
changes in the ordering of std::sort.

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

R600: Don't unconditionally unroll loops with private memory accesses

This causes the size of the scrypt kernel to explode and eats all the
memory on some systems.

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

R600/SI: Custom select 64-bit ADD

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

[SROA] Add an off-by-default *strict* inbounds check to SROA. I had SROA
implemented this way a long time ago and due to the overwhelming bugs
that surfaced, moved to a much more relaxed variant. Richard Smith would
like to understand the magnitude of this problem and it seems fairly
harmless to keep some flag-controlled logic to get the extremely strict
behavior here. I'll remove it if it doesn't prove useful.

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

Account for 128-bit integer operations in PPCCTRLoops

We need to abort the formation of counter-register-based loops where there are
128-bit integer operations that might become function calls.

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

Don't try to set a dummy DataLayout. It is parsed now.

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

Store a DataLayout in Module.

Now that DataLayout is not a pass, store one in Module.

Since the C API expects to be able to get a char* to the datalayout description,
we have to keep a std::string somewhere. This patch keeps it in Module and also
uses it to represent modules without a DataLayout.

Once DataLayout is mandatory, we should probably move the string to DataLayout
itself since it won't be necessary anymore to represent the special case of a
module without a DataLayout.

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

Debug info: Support variadic functions.
Variadic functions have an unspecified parameter tag after the last
argument. In IR this is represented as an unspecified parameter in the
subroutine type.

Paired commit with CFE r202185.

rdar://problem/13690847

This re-applies r202184 + a bugfix in DwarfDebug's argument handling.

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