| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch teaches ias for mips to handle expressions such as
(8*4)+(8*31)($sp). Such expression typically occur from the expansion
of multiple macro definitions.
This partially resolves PR/30383.
Thanks to Sean Bruno for reporting the issue!
Reviewers: zoran.jovanovic, vkalintiris
Differential Revision: https://reviews.llvm.org/D24667
llvm-svn: 284485
|
|
|
|
|
|
|
|
|
| |
Needs to be investigated. This is failing locally and on the
Xcode CI.
rdar://28805064
llvm-svn: 284484
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The 'sync' instruction for MIPS was defined in MIPS-II as taking no operands.
MIPS32 extended the define of 'sync' as taking an optional unsigned 5 bit
immediate.
This patch correct the definition of sync so that it is accepted with an
operand of 0 or no operand for MIPS-II to MIPS-V, and a 5 bit unsigned
immediate for MIPS32 and later revisions.
Additionally a clear error is given when the MIPS32 version of sync is
used when targeting pre MIPS32.
This partially resolves PR/30714.
Thanks to Daniel Sanders for reporting this issue!
Reveiwers: vkalintiris
Differential Revision: https://reviews.llvm.org/D25672
llvm-svn: 284483
|
|
|
|
|
|
|
|
|
| |
In futher patches we shall have alignment field added to DIVariable family
and switching from uint64_t to uint32_t will save 4 bytes per variable.
Differential Revision: https://reviews.llvm.org/D25620
llvm-svn: 284482
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
ld and sd when assembled for the O32 ABI expand to a pair of 32 bit word loads
or stores using the specified source or destination register and the next
register.
This patch does not add support for the cases where the offset is greater than
a 16 bit signed immediate as that would lead to a wrong/misleading error
message as the assembler would report "instruction requires a CPU feature
not currently enabled" for ld & sd for MIPS64 when their offset is not a signed
16 bit number.
This fixes PR/29159.
Thanks to Sean Bruno for reporting this issue!
Reviewers: vkalintiris, seanbruno, zoran.jovanovic
Differential Review: https://reviews.llvm.org/D24556
llvm-svn: 284481
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Committing on behalf of Coby Tayree: After check-all and LGTM
Desc:
AVX512 allows dest operand to be followed by an op-mask register specifier ('{k<num>}', which in turn may be followed by a merging/zeroing specifier ('{z}')
Currently, the following forms are allowed:
{k<num>}
{k<num>}{z}
This patch allows the following forms:
{z}{k<num>}
and ignores the next form:
{z}
Justification would be quite simple - GCC
Differential Revision: http://reviews.llvm.org/D25013
llvm-svn: 284479
|
|
|
|
| |
llvm-svn: 284478
|
|
|
|
|
|
|
|
| |
In macros, 'do {...} while (0)' is often used. Don't warn about the condition 0 when it is unreachable.
Differential Revision: https://reviews.llvm.org/D25606
llvm-svn: 284477
|
|
|
|
| |
llvm-svn: 284476
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
support FastISel.
Summary:
Instead of instantiating the MipsFastISel class and checking if the
target is supported in the overriden methods, we should perform that
check before creating the class. This allows us to enable FastISel *only*
for targets that truly support it, ie. MIPS32 to MIPS32R5.
Reviewers: sdardis
Subscribers: ehostunreach, llvm-commits
Differential Revision: https://reviews.llvm.org/D24824
llvm-svn: 284475
|
|
|
|
| |
llvm-svn: 284474
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When dealing with objects that represent numbers, such as Objective-C NSNumber,
the language provides little protection from accidentally interpreting
the value of a pointer to such object as the value of the number represented
by the object. Results of such mis-interpretation may be unexpected.
The checker attempts to fill this gap in cases when the code is obviously
incorrect.
With "Pedantic" option enabled, this checker enforces a coding style to
completely prevent errors of this kind (off by default).
Differential Revision: https://reviews.llvm.org/D22968
llvm-svn: 284473
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This commit changes code completion results for Objective-C block properties:
clang now suggests an additional completion result that displays the block
property together with '=' and the block literal placeholder for the appropriate
readwrite block properties.
This commit uses a simple heuristic to determine when it's appropriate to
suggest a setter completion for block properties: the additional block setter
completion is provided iff the member access that's being completed is a
standalone statement.
rdar://28481726
Differential Revision: https://reviews.llvm.org/D25520
llvm-svn: 284472
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
PT_OPENBSD_RANDOMIZE/PT_OPENBSD_WXNEEDED headers.
These are OpenBSD specific program headers and
currently we support them in LLD.
Description of headers (just in case) available here:
http://man.openbsd.org/OpenBSD-current/man5/elf.5
OpenBSD commits were:
For PT_OPENBSD_RANDOMIZE:
https://github.com/openbsd/src/commit/c494713c450d98da3f2e1451ee8c7fb675a7c461
For PT_OPENBSD_WXNEEDED:
https://github.com/openbsd/src/commit/2a5a8fc7e30928c2cff57cfe5fb491c90d8478ad
Differential revision: https://reviews.llvm.org/D25616
llvm-svn: 284471
|
|
|
|
|
|
|
|
|
|
| |
Both gold and ld accepts integers instead of named constants
for PHDRS.
Patch adds support for that.
Differential revision: https://reviews.llvm.org/D25549
llvm-svn: 284470
|
|
|
|
|
|
|
| |
NetBSD does not have getopt as well - we need to apply the workaround there too.
FreeBSD seems to be fine though.
llvm-svn: 284469
|
|
|
|
|
|
|
|
|
|
| |
This commit extracts a new function named `formatBlockPlaceholder` from
the function `FormatFunctionParameter` so that it can be reused in follow-up
commits that improve code completion for block property setters.
Differential Revision: https://reviews.llvm.org/D25519
llvm-svn: 284468
|
|
|
|
|
|
|
|
|
|
| |
This commit extracts a new function named `findTypeLocationForBlockDecl` from
the function `FormatFunctionParameter` so that it can be reused in follow-up
commits that improve code completion for block property setters.
Differential Revision: https://reviews.llvm.org/D25519
llvm-svn: 284467
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
The dependencies of our libraries (only liblldb, really) we marked as public, which caused all
their dependencies to be repeated when linking any executables to them. This is a problem because
then all the .a files could end up being linked twice, once to liblldb and once
again to to the executable linking against liblldb (lldb, lldb-mi). As it turns out,
our build actually depends on this behavior:
- on windows, lldb does not have getopt, so it pulls it from inside liblldb, even
though getopt is not a part of the exported interface of liblldb (maybe some of
the bsd variants have this problem as well)
- lldb-mi uses llvm, which again is not exported by liblldb
This change does not actually fix these problems (that is going to be a hard
one), but it does make them explicit by moving this magic from add_lldb_library
to the places the executable targets are defined. That way, I can link the
additional .a files only on targets that really need it, and the other targets
can build cleanly and make sure we don't regress further. It also fixes the
LLVM_LINK_LLVM_DYLIB build on linux.
Reviewers: zturner, beanz
Subscribers: ki.stfu, lldb-commits, mgorny
Differential Revision: https://reviews.llvm.org/D25680
llvm-svn: 284466
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In loops that look something like
i = n;
do {
...
} while(i++ < n+k);
where k is a constant, the maximum backedge count is k (in fact the backedge
count will be either 0 or k, depending on whether n+k wraps). More generally
for LHS < RHS if RHS-(LHS of first comparison) is a constant then the loop will
iterate either 0 or that constant number of times.
This allows for more loop unrolling with the recent upper bound loop unrolling
changes, and I'm working on a patch that will let loop unrolling additionally
make use of the loop being executed either 0 or k times (we need to retain the
loop comparison only on the first unrolled iteration).
Differential Revision: https://reviews.llvm.org/D25607
llvm-svn: 284465
|
|
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D25673
llvm-svn: 284464
|
|
|
|
|
|
|
|
|
|
| |
CursorKind.OVERLOAD_CANDIDATE.
The test fails because the value does not lay in any existing group.
Differential Revision: https://reviews.llvm.org/D25470
llvm-svn: 284463
|
|
|
|
|
|
|
|
|
|
| |
This reverts commits 284436 and 284437 because they still break AArch64 bots:
Value of: format_number(-10, IntegerStyle::Integer, 1)
Actual: "-0"
Expected: "-10"
llvm-svn: 284462
|
|
|
|
|
|
| |
vXi64 will benefit more from lowering to shifts than multiplies
llvm-svn: 284461
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch assigns cost of the scaling used in addressing for Cortex-R52.
On Cortex-R52 a negated register offset takes longer than a non-negated
register offset, in a register-offset addressing mode.
Differential Revision: http://reviews.llvm.org/D25670
Reviewer: jmolloy
llvm-svn: 284460
|
|
|
|
|
|
|
|
|
|
|
|
| |
As discussed on PR28461 we currently miss the chance to lower "fptosi <2 x double> %arg to <2 x i32>" to cvttpd2dq due to its use of illegal types.
This patch adds support for fptosi to 2i32 from both 2f64 and 2f32.
It also recognises that cvttpd2dq zeroes the upper 64-bits of the xmm result (similar to D23797) - we still don't do this for the cvttpd2dq/cvttps2dq intrinsics - this can be done in a future patch.
Differential Revision: https://reviews.llvm.org/D23808
llvm-svn: 284459
|
|
|
|
|
|
|
| |
an assertion failure looking up a matching ::operator delete for
__builtin_operator_delete.
llvm-svn: 284458
|
|
|
|
|
|
|
|
|
| |
dependent noexcept specifications result in the same canonical function type.
We still use non-canonical hashing when deduplicating type sugar so that
diagnostics will point to the right place.
llvm-svn: 284457
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch adds simplified support for tail calls on ARM with XRay instrumentation.
Known issue: compiled with generic flags: `-O3 -g -fxray-instrument -Wall
-std=c++14 -ffunction-sections -fdata-sections` (this list doesn't include my
specific flags like --target=armv7-linux-gnueabihf etc.), the following program
#include <cstdio>
#include <cassert>
#include <xray/xray_interface.h>
[[clang::xray_always_instrument]] void __attribute__ ((noinline)) fC() {
std::printf("In fC()\n");
}
[[clang::xray_always_instrument]] void __attribute__ ((noinline)) fB() {
std::printf("In fB()\n");
fC();
}
[[clang::xray_always_instrument]] void __attribute__ ((noinline)) fA() {
std::printf("In fA()\n");
fB();
}
// Avoid infinite recursion in case the logging function is instrumented (so calls logging
// function again).
[[clang::xray_never_instrument]] void simplyPrint(int32_t functionId, XRayEntryType xret)
{
printf("XRay: functionId=%d type=%d.\n", int(functionId), int(xret));
}
int main(int argc, char* argv[]) {
__xray_set_handler(simplyPrint);
printf("Patching...\n");
__xray_patch();
fA();
printf("Unpatching...\n");
__xray_unpatch();
fA();
return 0;
}
gives the following output:
Patching...
XRay: functionId=3 type=0.
In fA()
XRay: functionId=3 type=1.
XRay: functionId=2 type=0.
In fB()
XRay: functionId=2 type=1.
XRay: functionId=1 type=0.
XRay: functionId=1 type=1.
In fC()
Unpatching...
In fA()
In fB()
In fC()
So for function fC() the exit sled seems to be called too much before function
exit: before printing In fC().
Debugging shows that the above happens because printf from fC is also called as
a tail call. So first the exit sled of fC is executed, and only then printf is
jumped into. So it seems we can't do anything about this with the current
approach (i.e. within the simplification described in
https://reviews.llvm.org/D23988 ).
Differential Revision: https://reviews.llvm.org/D25030
llvm-svn: 284456
|
|
|
|
|
|
|
|
| |
r284450.
This is harder to do for vpermilpd as shuffle combining turns the constant vector into an immediate since all vpermilpd's inputs with constant vector can also be encoded with the immediate form.
llvm-svn: 284455
|
|
|
|
|
|
|
|
| |
When Error was threaded through these APIs back in r265606 the
"return" was missed here, which triggers a warning if/when I add
LLVM_NODISCARD to the Error type.
llvm-svn: 284454
|
|
|
|
|
|
|
|
| |
a different type than the shuffle itself.
This is especially important for 32-bit targets with 64-bit shuffle elements.
llvm-svn: 284453
|
|
|
|
|
|
|
|
|
|
|
|
| |
-debug-only=subtarget-emitter prints a lot of machine model diagnostics.
This prunes the output so that the "No machine model for XXX on processor YYY"
only appears when there is definitely no machine model for that opcode.
Previously it was printing that error even if the opcode was covered by
a more general scheduling class.
<rdar://problem/15919845> [TableGen][CodeGenSchedule] Debug output does not help spotting the missing scheduling classes
llvm-svn: 284452
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
entry has a different type than the shuffle itself.
Summary: This is especially important for 32-bit targets with 64-bit shuffle elements.This is similar to how PSHUFB and VPERMIL handle the same problem.
Reviewers: RKSimon
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D25666
llvm-svn: 284451
|
|
|
|
|
|
| |
masked VPERMILPS/PD.
llvm-svn: 284450
|
|
|
|
| |
llvm-svn: 284448
|
|
|
|
| |
llvm-svn: 284446
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Move alpha.valist from potential to alpha since it was implemented in D15227
Cleanup some HTML comments, add a missing link
Reviewers: jordan_rose, zaks.anna
Subscribers: cfe-commits, xazax.hun
Differential Revision: https://reviews.llvm.org/D25663
llvm-svn: 284445
|
|
|
|
|
|
| |
COFF/InputFiles.h includes LTOModule.h which transitively relies on Attributes.inc.
llvm-svn: 284444
|
|
|
|
|
|
| |
This just passes through a few missing CMake variables for multi-stage builds.
llvm-svn: 284443
|
|
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D25711
llvm-svn: 284442
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
There are differences in codegen between Linux and Windows due to:
1. Using std::sort which uses quicksort which is a non-stable sort.
2. Iterating over Set data structure where the iteration order is
non deterministic.
Reviewers: arsenm, grosbach, junbuml, zinob, MatzeB
Subscribers: MatzeB, wdng
Differential Revision: https://reviews.llvm.org/D25695
llvm-svn: 284441
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This makes __llvm_profile_set_filename() work across dylib boundaries on
Darwin.
This functionality was originally meant to work on all platforms, but
was moved to a Linux-only directory with r272404. The root cause of the
test failure on Darwin was that lprofCurFilename was not marked weak.
Each dylib maintained its own copy of the variable due to the two-level
namespace.
Tested with check-profile (on Darwin). I don't expect this to regress
other platforms.
Differential Revision: https://reviews.llvm.org/D25707
llvm-svn: 284440
|
|
|
|
|
|
|
|
|
| |
In the expression command, if the target is NULL, you have to use the dummy
target.
<rdar://problem/28811687>
llvm-svn: 284439
|
|
|
|
|
|
| |
This should fix the remaining broken builds.
llvm-svn: 284437
|
|
|
|
|
|
|
|
|
|
| |
This resubmits commits 284425 and r284428, which were reverted
in r284429 due to some infinite recursion caused by an incorrect
selection of function overloads. Reproduced the failure on Linux
using GCC 4.8.4, and confirmed that with the new patch the tests
path on GCC as well as MSVC. So hopefully this fixes everything.
llvm-svn: 284436
|
|
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D25694
llvm-svn: 284435
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
CachedHashStringRef.
Summary:
Reclaiming the name 'CachedHashString' will let us add a type with that
name that owns its value.
Reviewers: timshen
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D25644
llvm-svn: 284434
|
|
|
|
|
|
|
|
|
|
| |
Reviewers: timshen
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D25629
llvm-svn: 284433
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: This matches SmallDenseMap.
Reviewers: timshen
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D25628
llvm-svn: 284432
|