MC: Cleanup parseMSInlineAsm

Utilize range based for-loops to simplify some code.
Use insert() instead of a loop for simplicity/efficiency.

No functionality change.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@211486 91177308-0d34-0410-b5e6-96231b3b80d8
ARM: mark UBFX as not allowing PC.

Strictly, it's unpredictable. But we don't quite model that yet and an error is
better than ignoring the issue. This one somehow got left out before though.

rdar://problem/15997748

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@211490 91177308-0d34-0410-b5e6-96231b3b80d8
[PowerPC] Fix on-stack AltiVec arguments with 64-bit SVR4

Current 64-bit SVR4 code seems to have some remnants of Darwin code
in AltiVec argument handing.  This had the effect that AltiVec arguments
(or subsequent arguments) were not correctly placed in the parameter area
in some cases.

The correct behaviour with the 64-bit SVR4 ABI is:
- All AltiVec arguments take up space in the parameter area, just like
  any other arguments, whether vararg or not.
- They are always 16-byte aligned, skipping a parameter area doubleword
  (and the associated GPR, if any), if necessary.

This patch implements the correct behaviour and adds a test case.
(Verified against GCC behaviour via the ABI compat test suite.)



git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@211492 91177308-0d34-0410-b5e6-96231b3b80d8
[PowerPC] Refactor setMinReservedArea and CalculateParameterAndLinkageAreaSize

The PPCISelLowering.cpp routines PPCTargetLowering::setMinReservedArea and
CalculateParameterAndLinkageAreaSize are currently used as subroutines
from both 64-bit SVR4 and Darwin ABI code.

However, the two ABIs are already quite different w.r.t. AltiVec
conventions, and they will become more different when the ELFv2 ABI is
supported.  Also, in general it seems better to disentangle ABI support
routines for different ABIs to avoid accidentally affecting one ABI when
intending to change only the other.

(Actually, the current code strictly speaking already contains a bug:
these routines call PPCFrameLowering::getMinCallFrameSize and
PPCFrameLowering::getLinkageSize with the IsDarwin parameter set to
"true" even on 64-bit SVR4.  This bug currently has no adverse effect
since those routines always return the same for 64-bit SVR4 and 64-bit
Darwin, but it still seems wrong ...  I'll fix this in a follow-up
commit shortly.)

To remove this code sharing, I'm simply inlining both routines into all
call sites (there are just two each, one for 64-bit SVR4 and one for
Darwin), and simplifying due to constant parameters where possible.

A small piece of code that *does* make sense to share is refactored into
the new routine EnsureStackAlignment, now also called from 32-bit SVR4
ABI code.

No change in generated code is expected.



git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@211493 91177308-0d34-0410-b5e6-96231b3b80d8
[PowerPC] Fix IsDarwin arg in PPCFrameLowering:: calls

As remarked in the commit message to r211493, in several places
throughout the 64-bit SVR4 ABI code there are calls to
PPCFrameLowering::getLinkageSize and getMinCallFrameSize
using an incorrect IsDarwin argument of "true".

(Some of those were made explicit by the above refactoring patch, others
have been there all along.)

This patch fixes those places to pass "false" for IsDarwin.

No change in generated code expected.



git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@211494 91177308-0d34-0410-b5e6-96231b3b80d8
[PowerPC] Allow stack frames without parameter save area

The PPCFrameLowering::determineFrameLayout routine currently ensures
that every function that allocates a stack frame provides space for the
parameter save area (via PPCFrameLowering::getMinCallFrameSize).

This is actually not necessary.  There may be functions that never call
another routine but still allocate a frame; those do not require the
parameter save area.  In the future, with the ELFv2 ABI, even some
routines that do call other functions do not need to allocate the
parameter save area.

While it is not a bug to allocate the parameter area when it is not
needed, it is better to avoid it to save stack space.

Note that when any particular function call requires the parameter save
area, this space will already have been included by ABI code in the size
the CALLSEQ_START insn is annotated with, and therefore included in the
size returned by MFI->getMaxCallFrameSize().

This means that determineFrameLayout simply does not need to care about
the parameter save area.  (It still needs to ensure that every frame
provides the linkage area.)  This is implemented by this patch.

Note that this exposed a bug in the new fast-isel code where the parameter
area was *not* included in the CALLSEQ_START size; this is also fixed.

A couple of test cases needed to be adapted for the new (smaller) stack
frame size those tests now see.



git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@211495 91177308-0d34-0410-b5e6-96231b3b80d8
[PowerPC] Refactor getMinCallFrameSize / getMinCallArgumentsSize

As of r211495, the only remaining users of getMinCallFrameSize are in
core ABI code (LowerFormalParameter / LowerCall).  This is actually a
good thing, since the details of the parameter save area are ABI specific.

With the new ELFv2 ABI in particular, the rules defining the size of the
save area will become significantly more complex, so it wouldn't make
sense to implement those outside ABI code that has all required
information.

In preparation, this patch eliminates the getMinCallFrameSize (and
associated getMinCallArgumentsSize) routines, and inlines them into all
callers.  Note that since nearly all call arguments are constant, this
allows simplifying the inlined copies to a single line everywhere.

No change in generate code expected.



git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@211497 91177308-0d34-0410-b5e6-96231b3b80d8
Remove a temporary hack.

Amusingly this survived a lot longer than the CFI transition. We don't even
support non-cfi assemblers any more.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@211498 91177308-0d34-0410-b5e6-96231b3b80d8
Stop producing func.eh symbols on Darwin.

According Nick Kledzik (http://llvm.org/bugs/show_bug.cgi?id=19430#c2):
"... mach-o no longer needs names in the __eh_frame section (and has not for
years)."

Iain Sandoe confirms it is also unnecessary for their old darwin support.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@211500 91177308-0d34-0410-b5e6-96231b3b80d8
clang-format initializer to reduce noise in another patch.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@211501 91177308-0d34-0410-b5e6-96231b3b80d8
Allow using .cfi_startproc without a leading symbol.

This is possible now that we don't produce .eh symbols. This fixes pr19430.

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