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.

rdar://problem/13690847

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

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@202186 91177308-0d34-0410-b5e6-96231b3b80d8
Revert "Debug info: Support variadic functions."

This reverts commit r202184 because of buildbot breakage.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@202187 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
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
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
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
[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
R600/SI: Custom select 64-bit ADD

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@202194 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
[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
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
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
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
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
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
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
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
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
Simplify base64 routine a bit.

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