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
Formatting fixups.

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

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@202221 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
[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
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] 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
[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