Only use them if the subtarget has ARM mode, as these routines are implemented
as ARM code.
rdar://15302004
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@193381 91177308-0d34-0410-b5e6-96231b3b80d8
Also improve the implementation of EmitRawText(Twine) so it doesn't
bother using the SmallString buffer if the Twine is a simple StringRef
anyway.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@193378 91177308-0d34-0410-b5e6-96231b3b80d8
This may've been used at some point but the 'print' member function grew
an Indent parameter that entirely shadows this parameter.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@193358 91177308-0d34-0410-b5e6-96231b3b80d8
This commit changes the struct byval lowering for arm to use inline
checks for the subtarget instead of a class abstraction to represent
the differences. The class abstraction was judged to be too much
code for this task.
No intended functionality change.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@193357 91177308-0d34-0410-b5e6-96231b3b80d8
This prevents us from silently accepting invalid instructions on (for example)
Cortex-M4 with just single-precision VFP support.
No tests for the extra Pat Requires because they're essentially assertions: the
affected code should have been lowered to libcalls before ISel.
rdar://problem/15302004
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@193354 91177308-0d34-0410-b5e6-96231b3b80d8
Make sure we mark all loops (scalar and vector) when vectorizing,
so that we don't try to vectorize them anymore. Also, set unroll
to 1, since this is what we check for on early exit.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@193349 91177308-0d34-0410-b5e6-96231b3b80d8
The fused multiply instructions were added in VFPv4 but are still NEON
instructions, in particular they shouldn't be available on a Cortex-M4 not
matter how floaty it is.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@193342 91177308-0d34-0410-b5e6-96231b3b80d8
If an alias inherits directly from InstAlias then it doesn't get any default
"Requires" values, so llvm-mc will allow it even on architectures that don't
support the underlying instruction.
This tidies up the obvious VFP and NEON cases I found.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@193340 91177308-0d34-0410-b5e6-96231b3b80d8
The compiler-rt functions __adddf3vfp and so on exist purely to allow Thumb1
code to make use of VFP instructions by switching back to ARM mode, they make
no sense for M-class processors which don't even have an ARM mode.
Given that justification, in practice this is a platform ABI decision so the
actual check is based on that rather than CPU features.
rdar://problem/15302004
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@193327 91177308-0d34-0410-b5e6-96231b3b80d8
Without this, customers of the MCJIT were leaking memory like crazy.
It's not really clear what the *right* memory management is here, so I'm
not trying to add lots of tests or other logic, just trying to get us
back to a better baseline. I'll follow up on the original commit to
figure out the right path forward.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@193323 91177308-0d34-0410-b5e6-96231b3b80d8
POP instructions are aliased to the ARM LDM variants but have different syntax.
This caused two problems: we tried to access a non-existent operand to annotate
the '!', and the error message didn't make much sense.
With some vigorous hand-waving in the error message both problems can be
fixed.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@193322 91177308-0d34-0410-b5e6-96231b3b80d8
LLVM optimizers may widen accesses to packed structures that overflow the structure itself, but should be in bounds up to the alignment of the object
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@193317 91177308-0d34-0410-b5e6-96231b3b80d8
When generating the IfTrue basic block during the F128CSEL pseudo-instruction
handling, the NZCV live-in for the newly created BB wasn't being added. This
caused a fault during MI-sched/live range calculation when the predecessor
for the fall-through BB didn't have a live-in for phys-reg as expected.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@193316 91177308-0d34-0410-b5e6-96231b3b80d8
This was a fundamental flaw in llvm-cov where it treated the values in
the GCDA files as block counts instead of edge counts. This created
incorrect line counts when branching was present. Instead, the edge
counts should be summed to obtain the correct block count.
The fix was tested using custom test files as well as single source
files from the test-suite directory. The behaviour can be verified by
reading the GCOV documentation that describes the GCDA spec ("ARC_COUNTS
gives the counter values for those arcs that are instrumented") and the
header description provided by GCOVProfiling.cpp ("instruments the code
that runs to records (sic) the edges between blocks that run and emit a
complementary "gcda" file on exit").
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@193299 91177308-0d34-0410-b5e6-96231b3b80d8
Calling _chkstk is required on ELF as well as COFF on Windows. Without
_chkstk, functions requiring large stack crash in initialization code.
Previous code tested for COFF format but not Mach-O and this patch modifies
the code to test for Windows OS (both Windows target and MingW target)
but not Mach-O object format: Looks like macho environment was used to
build some EFI code.
Credits to Andrew MacPherson.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@193289 91177308-0d34-0410-b5e6-96231b3b80d8
Since we never insert DIE for DITemplateTypeParameter to a map, there is no need
to call getDIE in getOrCreateTemplateTypeParameterDIE. It is also renamed to
constructTemplateTypeParameterDIE to match with other construct functions
in CompileUnit.
Same applies to getOrCreateTemplateValueParameterDIE.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@193287 91177308-0d34-0410-b5e6-96231b3b80d8
Remove the unneeded return values from createMemberDIE, constructEnumTypeDIE,
getOrCreateTemplateTypeParameterDIE, and getOrCreateTemplateValueParameterDIE.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@193285 91177308-0d34-0410-b5e6-96231b3b80d8
There are a few motivations for this:
- Using a map allows for checking if line is in map. This differentiates
unexecutable lines (such as comments) from unexecuted logical lines of
code. "#####" is now outputted in this case, in line with gcov.
- Source files are no longer read in twice: once when storing the line
counts, and once when outputting the data.
- Greatly simplifies the function FileInfo::addLineCount().
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@193264 91177308-0d34-0410-b5e6-96231b3b80d8
Without _chkstk functions requiring large stack crash in
initialization code. Previous code tested for COFF format but
not Mach-O and this patch modifies the code to test for Windows.
Credits to Andrew MacPherson.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@193263 91177308-0d34-0410-b5e6-96231b3b80d8
On sandy bridge (PR17654) we now get
vpxor %xmm1, %xmm1, %xmm1
vpunpckhbw %xmm1, %xmm0, %xmm2
vpunpcklbw %xmm1, %xmm0, %xmm0
vinsertf128 $1, %xmm2, %ymm0, %ymm0
On haswell it's a simple
vpmovzxbw %xmm0, %ymm0
There is a maze of duplicated and dead transforms and patterns in this
area. Remove the dead custom lowering of zext v8i16 to v8i32, that's
already handled by LowerAVXExtend.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@193262 91177308-0d34-0410-b5e6-96231b3b80d8
- Skip instructions added in prolog. For specific targets, prolog may
insert helper function calls (e.g. _chkstk will be called when
there're more than 4K bytes allocated on stack). However, these
helpers don't use/def YMM/XMM registers.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@193261 91177308-0d34-0410-b5e6-96231b3b80d8
Major steps include:
1). introduces a not-addr-taken bit-field in GlobalVariable
2). GlobalOpt pass sets "not-address-taken" if it proves a global varirable
dosen't have its address taken.
3). AA use this info for disambiguation.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@193251 91177308-0d34-0410-b5e6-96231b3b80d8
