We were using RAT_INST_STORE_RAW, which seemed to work, but the docs
say this instruction doesn't exist for Cayman, so it's probably safer
to use a documented instruction instead.
Reviewed-by: Vincent Lejeune<vljn at ovi.com>
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@184015 91177308-0d34-0410-b5e6-96231b3b80d8
It looks like clang-tools-extra/unittests/cpp11-migrate/TransformTest.cpp
depends on the behaviour of the old one on Windows. Maybe a difference
between GetCurrentDirectoryA and GetCurrentDirectoryW?
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@184009 91177308-0d34-0410-b5e6-96231b3b80d8
When we're rematerializing into a not-quite-right register we already add the
real definition as an imp-def, but we should also be marking the "official"
register as dead, since nothing else is going to use it as a result of this
remat.
Not doing this can affect pressure tracking.
rdar://problem/14158833
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@184002 91177308-0d34-0410-b5e6-96231b3b80d8
in functions which call __builtin_unwind_init()
__builtin_unwind_init() is an undocumented gcc intrinsic which has this effect,
and is used in libgcc_eh.
Goes part of the way toward fixing PR8541.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@183984 91177308-0d34-0410-b5e6-96231b3b80d8
This is a resubmit of r182877, which was reverted because it broken
MCJIT tests on ARM. The patch leaves MCJIT on ARM as it was before: only
enabled for iOS. I've CC'ed people from the original review and revert.
FastISel was only enabled for iOS ARM and Thumb2, this patch enables it
for ARM (not Thumb2) on Linux and NaCl, but not MCJIT.
Thumb2 support needs a bit more work, mainly around register class
restrictions.
The patch punts to SelectionDAG when doing TLS relocation on non-Darwin
targets. I will fix this and other FastISel-to-SelectionDAG failures in
a separate patch.
The patch also forces FastISel to retain frame pointers: iOS always
keeps them for backtracking (so emitted code won't change because of
this), but Linux was getting much worse code that was incorrect when
using big frames (such as test-suite's lencod). I'll also fix this in a
later patch, it will probably require a peephole so that FastISel
doesn't rematerialize frame pointers back-to-back.
The test changes are straightforward, similar to:
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20130513/174279.html
They also add a vararg test that got dropped in that change.
I ran all of lnt test-suite on A15 hardware with --optimize-option=-O0
and all the tests pass. All the tests also pass on x86 make check-all. I
also re-ran the check-all tests that failed on ARM, and they all seem to
pass.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@183966 91177308-0d34-0410-b5e6-96231b3b80d8
For consistency, change the address in the test case from 0xDEADBEEF to
0xCAFEBABE since 0xCAFEBABE that actually has a 2-byte alignment.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@183962 91177308-0d34-0410-b5e6-96231b3b80d8
The current functionality is extremely basic and a bit rough around the
edges, but it will flesh out in future commits.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@183953 91177308-0d34-0410-b5e6-96231b3b80d8
This pass was assuming that if hasAddressTaken() returns false for a
function, the function's only uses are call sites. That's not true
because there can be references by BlockAddresses too.
Fix the pass to handle this case. Fix
BlockAddress::replaceUsesOfWithOnConstant() to allow a function's type
to be changed by RAUW'ing the function with a bitcast of the recreated
function.
Patch by Mark Seaborn.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@183933 91177308-0d34-0410-b5e6-96231b3b80d8
This is in preparation for switching the clang driver over to using LLVM's
Option library. Richard Smith introduced most of these changes to the clang
driver in r167638.
Reviewers: espindola on IRC
Differential Revision: http://llvm-reviews.chandlerc.com/D970
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@183925 91177308-0d34-0410-b5e6-96231b3b80d8
Execute's Data parameter is now optional, so we won't allocate memory
for it on Windows and we'll close the process handle.
The Unix code should probably do something similar to avoid accumulation
of zombie children that haven't been waited on.
Tested on Linux and Windows.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@183906 91177308-0d34-0410-b5e6-96231b3b80d8
operator<< so that functions are printed as just their name instead of as their
entire definition, which is excessively verbose in this context.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@183871 91177308-0d34-0410-b5e6-96231b3b80d8
It was only used to implement ExecuteAndWait and ExecuteNoWait. Expose just
those two functions and make Execute and Wait implementations details.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@183864 91177308-0d34-0410-b5e6-96231b3b80d8
Now that the PRED_BAD has been removed, this is failing the Clang
-Werror build due to -Wcovered-switch-default.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@183863 91177308-0d34-0410-b5e6-96231b3b80d8
I'm taking David Blaikie's suggestion to use an
Optional<PPC::Predicate> return value instead. That's the right
solution for this problem. Thanks for pointing out that possibility!
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@183858 91177308-0d34-0410-b5e6-96231b3b80d8
This is a preparatory patch for fast-isel support. The instruction
selector will need to access some functions in PPCGenCallingConv.inc,
which in turn requires several helper functions to be defined. These
are currently defined near the only use of PCCGenCallingConv.inc,
inside PPCISelLowering.cpp. This patch moves the declaration of the
functions into the associated header file to provide the needed
visibility.
No functional change intended.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@183844 91177308-0d34-0410-b5e6-96231b3b80d8
Allows returning a PPC::Predicate from a function with a no-predicate
value possible. Preparatory patch for fast-isel on PPC64 ELF. No
behavioral change intended.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@183841 91177308-0d34-0410-b5e6-96231b3b80d8
I've been comparing the object file output of LLVM's integrated
assembler against the external assembler on PowerPC, and one
area where differences still remain are in DWARF sections.
In particular, the GNU assembler generates .debug_frame and
.debug_line sections using a code alignment factor of 4, since
all PowerPC instructions have size 4 and must be aligned to a
multiple of 4. However, current MC code hard-codes a code
alignment factor of 1.
This patch changes this by adding a "minimum instruction alignment"
data element to MCAsmInfo and using this as code alignment factor.
This requires passing a MCContext into MCDwarfLineAddr::Encode
and MCDwarfLineAddr::EncodeAdvanceLoc. Note that one caller,
MCDwarfLineAddr::Write, didn't actually have that information
available. However, it turns out that this routine is in fact
never used in the whole code base, so the patch simply removes
it. If it turns out to be needed again at a later time, it
could be re-added with an updated interface.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@183834 91177308-0d34-0410-b5e6-96231b3b80d8
`typeinfo for llvm:🆑:GenericOptionValue').
Remove an "anchor" method for an abstract class. (This does not
increase the number of vtables.)
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@183830 91177308-0d34-0410-b5e6-96231b3b80d8
The pass emits a call to sqrt that has attribute "read-none". This call will be
converted to an ISD::FSQRT node during DAG construction, which will turn into
a mips native sqrt instruction.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@183802 91177308-0d34-0410-b5e6-96231b3b80d8
Most clients have already been moved from Path V1 to V2. The ones using V1
now include PathV1.h explicitly.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@183801 91177308-0d34-0410-b5e6-96231b3b80d8
Sign- and zero-extension folding was slightly incorrect because it wasn't checking that the shift on extensions was zero. Further, I recently added AND rd, rn, #255 as a form of 8-bit zero extension, and failed to add the folding code for it.
This patch fixes both issues.
This patch fixes both, and the test should remain the same:
test/CodeGen/ARM/fast-isel-fold.ll
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@183794 91177308-0d34-0410-b5e6-96231b3b80d8
For ARM on linux we use /proc/cpuinfo to detect the host CPU's features.
Linux derives these values without ever looking at the vendor of the
specific CPU implementation. Hence, it adds little value, if we parse
the output of /proc/cpuinfo only for certain vendors.
This patch enables us to derive the correct feature flags e.g. for Qualcomm
CPUs.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@183790 91177308-0d34-0410-b5e6-96231b3b80d8
Instead of a custom implementation of replaceAllUsesWith, we just call
replaceAllUsesWith and recreate llvm.used and llvm.compiler-used.
This change is particularity interesting because it makes llvm see
through what clang is doing with static used functions in extern "C"
contexts. With this change, running clang -O2 in
extern "C" {
__attribute__((used)) static void foo() {}
}
produces
@llvm.used = appending global [1 x i8*] [i8* bitcast (void ()* @foo to
i8*)], section "llvm.metadata"
define internal void @foo() #0 {
entry:
ret void
}
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@183756 91177308-0d34-0410-b5e6-96231b3b80d8
It will be tested in the next commit which moves another user to identify_magic.
Original message:
Fix an out of bounds array access.
We were looking at Magic[5] without checking Length. Since this path would not
return unless Length >= 18 anyway, just move the >= 18 check up.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@183753 91177308-0d34-0410-b5e6-96231b3b80d8
This enables the compiler to see the enum and produce warnings about a switch
not being fully covered. Fix one of these warnings.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@183749 91177308-0d34-0410-b5e6-96231b3b80d8
The effect of llvm.used is to introduce an invisible reference, so this seems
a reasonable restriction. It will be used to provide an easy ordering of
the entries in llvm.used.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@183743 91177308-0d34-0410-b5e6-96231b3b80d8
Negative zero is returned by the primary expression parser as INT32_MIN, so all that the method needs to do is to accept this value.
Behavior already present for Thumb2.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@183734 91177308-0d34-0410-b5e6-96231b3b80d8
- Don't use assert(0), or tests may pass or fail according to assertions.
- For now, The tests are marked as XFAIL for win32 hosts.
FIXME: Could we avoid XFAIL to specify triple in the RUN lines?
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@183728 91177308-0d34-0410-b5e6-96231b3b80d8
Currently, only emitting the ELF header is supported (no sections or
segments).
The ELFYAML code organization is broadly similar to the COFFYAML code.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@183711 91177308-0d34-0410-b5e6-96231b3b80d8
Some ARM CPUs only support ARM mode (ancient v4 ones, for example) and some
only support Thumb mode (M-class ones currently). This makes sure such CPUs
default to the correct mode and makes the AsmParser diagnose an attempt to
switch modes incorrectly.
rdar://14024354
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@183710 91177308-0d34-0410-b5e6-96231b3b80d8
Previously LEA64_32r went through virtually the entire backend thinking it was
using 32-bit registers until its blissful illusions were cruelly snatched away
by MCInstLower and 64-bit equivalents were substituted at the last minute.
This patch makes it behave normally, and take 64-bit registers as sources all
the way through. Previous uses (for 32-bit arithmetic) are accommodated via
SUBREG_TO_REG instructions which make the types and classes agree properly.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@183693 91177308-0d34-0410-b5e6-96231b3b80d8
A plain "sc" without argument is supposed to be treated like "sc 0"
by the assembler. This patch adds a corresponding alias.
Problem reported by Joerg Sonnenberger.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@183687 91177308-0d34-0410-b5e6-96231b3b80d8
The extended branch mnemonics are supposed to use an implied CR0
if there is no explicit condition register specified. This patch
adds extra variants of the mnemonics to this effect.
Problem reported by Joerg Sonnenberger.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@183686 91177308-0d34-0410-b5e6-96231b3b80d8
This patch removes some redundancy by generating the extended branch
mnemonics via a multiclass.
No change in behaviour expected.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@183685 91177308-0d34-0410-b5e6-96231b3b80d8
We were looking at Magic[5] without checking Length. Since this path would not
return unless Length >= 18 anyway, just move the >= 18 check up.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@183666 91177308-0d34-0410-b5e6-96231b3b80d8
the Mips16 port. A few of the psuedos could either take signed
or unsigned arguments and I did not distinguish the case and improperly
rejected some valid cases that the assembler had previously accepted
when they were pure pseudos that expanded as assembly instructions.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@183633 91177308-0d34-0410-b5e6-96231b3b80d8
Changes to ARM unwind opcode assembler:
* Fix multiple .save or .vsave directives. Besides, the
order is preserved now.
* For the directives which will generate multiple opcodes,
such as ".save {r0-r11}", the order of the unwind opcode
is fixed now, i.e. the registers with less encoding value
are popped first.
* Fix the $sp offset calculation. Now, we can use the
.setfp, .pad, .save, and .vsave directives at any order.
Changes to test cases:
* Add test cases to check the order of multiple opcodes
for the .save directive.
* Fix the incorrect $sp offset in the test case. The
stack pointer offset specified in the test case was
incorrect. (Changed test cases: ehabi-mc-section.ll and
ehabi-mc.ll)
* The opcode to restore $sp are slightly reordered. The
behavior are not changed, and the new output is same
as the output of GNU as. (Changed test cases:
eh-directive-pad.s and eh-directive-setfp.s)
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@183627 91177308-0d34-0410-b5e6-96231b3b80d8
Variadic functions are particularly fragile in the face of ABI changes, so this
limits how much the pass changes them
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@183625 91177308-0d34-0410-b5e6-96231b3b80d8
The register classes when emitting loads weren't quite restricting enough, leading to MI verification failure on the result register.
These are new failures that weren't there the first time I tried enabling ARM FastISel for new targets.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@183624 91177308-0d34-0410-b5e6-96231b3b80d8
Handle the case when the disassembler table can't tell
the difference between some encodings of QADD and CPS.
Add some necessary safe guards in CPS decoding as well.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@183610 91177308-0d34-0410-b5e6-96231b3b80d8
r183584 tries to derive some info from the code *AFTER* a call and apply
these derived info to the code *BEFORE* the call, which is not always safe
as the call in question may never return, and in this case, the derived
info is invalid.
Thank Duncan for pointing out this potential bug.
rdar://14073661
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@183606 91177308-0d34-0410-b5e6-96231b3b80d8
sys::IdentifyFileType is already conscious of the length, and
object_error::invalid_file_type is returned below anyway if
sys::IdentifyFileType doesn't recognize the file.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@183605 91177308-0d34-0410-b5e6-96231b3b80d8
instantiation issue with non-standard type.
Add a backend option to warn on a given stack size limit.
Option: -mllvm -warn-stack-size=<limit>
Output (if limit is exceeded):
warning: Stack size limit exceeded (<actual size>) in <functionName>.
The longer term plan is to hook that to a clang warning.
PR:4072
<rdar://problem/13987214>.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@183595 91177308-0d34-0410-b5e6-96231b3b80d8
This is using a hint from AMD APP OpenCL Programming Guide with
empirically tweaked parameters.
I used Unigine Heaven 3.0 to determine best parameters on my system
(i7 2600/Radeon 6950/Kernel 3.9.4) the benchmark :
it went from 38.8 average fps to 39.6, which is ~3% gain.
(Lightmark 2008.2 gain is much more marginal: from 537 to 539)
There is no lit test provided as the parameter were determined
empirically and it it would be nearly impossiblet to find a test
program that check for optimal behavior.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@183593 91177308-0d34-0410-b5e6-96231b3b80d8
