| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
llvm-svn: 280687
|
|
|
|
|
|
|
|
|
|
|
|
| |
Use ADT/BitmaskEnum for DINode::DIFlags for the following purposes:
* Get rid of unsigned int for flags to avoid problems on platforms with sizeof(int) < 4
* Flags are now strongly typed
Patch by: Victor Leschuk <vleschuk@gmail.com>
Differential Revision: https://reviews.llvm.org/D23766
llvm-svn: 280686
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The latest MSVC update apparently resolve the call from the
const ref variant to itself, leading to an infinite
recursion. It is not clear to me why the r-value overload is
not selected. `ValueT` is a pointer type, and the functional-style
cast in the call `insert_as(ValueT(V), LookupKey);` should result
in a r-value ref. A bug in MSVC?
Differential Revision: https://reviews.llvm.org/D23956
llvm-svn: 280685
|
|
|
|
| |
llvm-svn: 280684
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
All of the builtins are designed to be invoked with ARM AAPCS CC even on ARM
AAPCS VFP CC hosts. Tweak the default initialisation to ARM AAPCS CC rather
than C CC for ARM/thumb targets.
The changes to the tests are necessary to ensure that the calling convention for
the lowered library calls are honoured. Furthermore, these adjustments cause
certain branch invocations to change to branch-and-link since the returned value
needs to be moved across registers (d0 -> r0, r1).
llvm-svn: 280683
|
|
|
|
|
|
|
|
| |
instructions for 128/256-bit vectors and scalar single/double.
Still need to fix the register classes to allow the extended range of registers.
llvm-svn: 280682
|
|
|
|
|
|
| |
Add command lines for AVX and AVX512 feature sets.
llvm-svn: 280681
|
|
|
|
|
|
| |
cases. Add a command line for SKX features too.
llvm-svn: 280680
|
|
|
|
|
|
|
| |
The script (utils/update_test_checks.py) seems to have problems
with variable names that start with the same string.
llvm-svn: 280679
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Move early uses of spilled variables after CoroBegin.
For example, if a parameter had address taken, we may end up with the code
like:
define @f(i32 %n) {
%n.addr = alloca i32
store %n, %n.addr
...
call @coro.begin
This patch fixes the problem by moving uses of spilled variables after CoroBegin.
Reviewers: majnemer
Subscribers: mehdi_amini, llvm-commits
Differential Revision: https://reviews.llvm.org/D24234
llvm-svn: 280678
|
|
|
|
|
|
|
|
|
|
| |
This is effectively a revert of:
https://reviews.llvm.org/rL280115
And this should fix
https://llvm.org/bugs/show_bug.cgi?id=30281:
llvm-svn: 280677
|
|
|
|
|
|
| |
http://lab.llvm.org:8011/builders/clang-cmake-armv7-a15/builds/14952/steps/ninja%20check%201/logs/FAIL%3A%20LLVM%3A%3Aicmp.ll
llvm-svn: 280676
|
|
|
|
|
|
|
|
|
|
|
|
| |
As Pavel pointed out in a comment on llvm.org/pr30271, the VPATH I was
using here to eliminate duplication of a .cpp file had a side effect of
attempting to pull in a .o/.obj file from that same parent dir, where
other tests can be running in parallel. This is no good.
For now, I have removed the VPATH, which should address
llvm.org/pr30271. I have also removed the XFAIL.
llvm-svn: 280675
|
|
|
|
|
|
|
|
|
|
| |
Lots of unittests started failing under asan after r280455. It seems
they've been failing for a long time, but lit silently ignored them.
Downgrade the error so we can figure out what is going on.
Filed http://llvm.org/PR30285.
llvm-svn: 280674
|
|
|
|
|
|
|
|
| |
X86InstrInfo::copyPhysReg and simplify. No functional change intended.
The code is now written in terms of source and dest classes with feature checks inside each type of copy instead of having separate functions for each feature set.
llvm-svn: 280673
|
|
|
|
|
|
|
| |
I'm in the progress of adding ARMv6 support to CloudABI. On the compiler
side, everything seems to work properly with this tiny change applied.
llvm-svn: 280672
|
|
|
|
|
|
| |
'Failure to recognise i64 sitofp/uitofp conversions that can be performed as i32'
llvm-svn: 280671
|
|
|
|
|
|
| |
'Failure to recognise uitofp conversions that can be performed as sitofp'
llvm-svn: 280670
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
During building of recent compiler-rt sources on FreeBSD for arm, I
noticed that our unwind.h (which originates in libunwind) was missing
the `_US_ACTION_MASK` constant:
compiler-rt/lib/builtins/gcc_personality_v0.c:187:18: error: use of undeclared identifier '_US_ACTION_MASK'
if ((state & _US_ACTION_MASK) != _US_UNWIND_FRAME_STARTING)
^
It appears that both clang's internal unwind.h, and libgcc's unwind.h
define this constant as 3, so let's add this to libunwind's version too.
Reviewers: logan, kledzik, davide, emaste
Subscribers: joerg, davide, aemerson, emaste, llvm-commits
Differential Revision: https://reviews.llvm.org/D24222
llvm-svn: 280669
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
The Intel(R) Memory Protection Extensions (Intel(R) MPX) associates pointers
to bounds, against which the software can check memory references to
prevent out of bound memory access.
This patch allows accessing the MPX registers:
* bnd0-3: 128-bit registers to hold the bound values,
* bndcfgu, bndstatus: 64-bit configuration registers,
This patch also adds read/write tests for the MPX registers in the register
command tests and adds a new subdirectory for MPX specific tests.
Signed-off-by: Valentina Giusti <valentina.giusti@intel.com>
Reviewers: labath, granata.enrico, lldb-commits, clayborg
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D24187
llvm-svn: 280668
|
|
|
|
| |
llvm-svn: 280667
|
|
|
|
|
|
| |
calculation
llvm-svn: 280666
|
|
|
|
|
|
| |
calculation
llvm-svn: 280665
|
|
|
|
|
|
|
|
|
| |
On most architectures the linker is required to optimize away any
references to __tls_get_addr in case of static linking. As usual
a special case is MIPS - libc defines __tls_get_addr itself because
there are no TLS optimizations for this architecture.
llvm-svn: 280664
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Replace uses of the local MIUtilParse::CRegexParser class with the LLVM support class llvm::Regex. This reduces duplication of code, and makes it possible to remove the MIUtilParse::CRegexParser class that requires LLVM internal implementation headers.
Bug: https://llvm.org/bugs/show_bug.cgi?id=29138
Reviewers: dawn, abidh, ki.stfu
Subscribers: labath, ki.stfu, lldb-commits
Differential Revision: https://reviews.llvm.org/D23882
Author: Michał Górny <mgorny@gentoo.org>
llvm-svn: 280662
|
|
|
|
| |
llvm-svn: 280661
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This test code previously caused a failure in the module verifier,
because SimplifyCFG created this invalid instruction, which tries to
take the address of inline asm:
%.sink = select i1 %1, i64 ()* asm "mov $0, #1", "=r", i64 ()* asm %"mov $0, #2", "=r"
This has been fixed recently, presumably by James Molloy's patches that
re-wrote and changed parts of SimplifyCFG, so this patch just adds a
regression test for it.
Differential Revision: https://reviews.llvm.org/D24231
llvm-svn: 280660
|
|
|
|
| |
llvm-svn: 280659
|
|
|
|
|
|
| |
r280613 introduced failures for all builds that don't target x86 by default. Add an explicit target to avoid a missing feature diagnostic.
llvm-svn: 280658
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When optimizing, GCC optimizes away aggressively unused static globals.
The __asan_before_dynamic_init/__asan_after_dynamic_init calls are placed
in static constructor earlier while the registration of the globals is done
later in the compilation process. If all the globals with
dynamic initialization are optimized away from some particular TU in between
those two, libasan can fail on an assertion that dynamic_init_globals is
empty.
While I'm going to commit a GCC change which will remove the
__asan_before_dynamic_init/__asan_after_dynamic_init in many cases when this
happens (basically if the optimizers can prove there are no memory
references in between the two calls), there are still testcases where such
pair of calls is left, e.g. for
struct S { S () { asm volatile ("" : : : "memory"); } };
static S c;
int
main ()
{
return 0;
}
with -O2 -fsanitize=address and ASAN_OPTIONS=check_initialization_order=true
this still fails the assertion. Trying to avoid this problem on the
compiler side would decrease code quality I'm afraid, whether it is making
sure for -fsanitize=address we keep around at least one dynamically
initialized global if the
__asan_before_dynamic_init/__asan_after_dynamic_init pair has been emitted,
or adding some artificial global which would be used as the condition for
those calls etc.
So, can the assertion be instead just removed, this really shouldn't slow
down the calls measurably (for __asan_before_dynamic_init it is even
cheaper) and the assertion doesn't check something worthwhile anyway (it is
sufficient if there is a single dynamically initialized global in any other
TU to make it happy).
Details in http://gcc.gnu.org/PR77396
Author: Jakub Jelinek
llvm-svn: 280657
|
|
|
|
|
|
| |
Not sure why ADL isn't working here.
llvm-svn: 280656
|
|
|
|
|
|
| |
Differential revision: https://reviews.llvm.org/D24072
llvm-svn: 280655
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The check-polly-tests target runs regression/unit tests but without checking
formatting. This is useful to not having to reload a file in an open editor
(which eg. clears the undo buffer, moves cursor/window position) when running
polly-update-format.
After this change, the following test targets exist:
- check-polly-unittests to run unittests only
- check-polly-tests to run unit and regression tests
- polly-check-format to check formatting using clang-format
- check-polly to run them all
As a side-effect, when running check-polly, polly-check-format and run in
parallel (instead of polly-check-format first).
Differential Revision: https://reviews.llvm.org/D24191
llvm-svn: 280654
|
|
|
|
| |
llvm-svn: 280653
|
|
|
|
|
|
| |
android targets use this key, so the test should recognize it.
llvm-svn: 280652
|
|
|
|
|
|
|
|
| |
These need to be mapped through to R_ARM_THM_JUMP{11,8} respectively.
Fixes PR30279.
llvm-svn: 280651
|
|
|
|
|
|
|
|
| |
upper bits.
Differential Revision: http://reviews.llvm.org/D23983
llvm-svn: 280650
|
|
|
|
| |
llvm-svn: 280649
|
|
|
|
|
|
|
|
| |
AVX512, but not VLX. We should use the VEX opcodes and trust the register allocator to not use the extended XMM/YMM register space.
Previously we were extending to copying the whole ZMM register. The register allocator shouldn't use XMM16-31 or YMM16-31 in this configuration as the instructions to spill them aren't available.
llvm-svn: 280648
|
|
|
|
|
|
| |
was a private member with no code reading from it.
llvm-svn: 280647
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
A frontend may designate a particular suspend to be final, by setting the second argument of the coro.suspend intrinsic to true. Such a suspend point has two properties:
* it is possible to check whether a suspended coroutine is at the final suspend point via coro.done intrinsic;
* a resumption of a coroutine stopped at the final suspend point leads to undefined behavior. The only possible action for a coroutine at a final suspend point is destroying it via coro.destroy intrinsic.
This patch adds final suspend handling logic to CoroEarly and CoroSplit passes.
Now, the final suspend point example from docs\Coroutines.rst compiles and produces expected result (see test/Transform/Coroutines/ex5.ll).
Reviewers: majnemer
Subscribers: mehdi_amini, llvm-commits
Differential Revision: https://reviews.llvm.org/D24068
llvm-svn: 280646
|
|
|
|
| |
llvm-svn: 280645
|
|
|
|
|
|
|
|
|
|
| |
placement in the td file they had lower precedence than (V)MOVSS/SD and could almost never be selected.
The only way to select them was in AVX512 mode because EVEX VMOVSS/SD was below them and the patterns weren't qualified properly for AVX only. So if you happened to have an aligned FR32/FR64 load in AVX512 you could get a VEX encoded VMOVAPS/VMOVAPD.
I tried to search back through history and it seems like these instructions were probably unselectable for at least 5 years, at least to the time the VEX versions were added. But I can't prove they ever were.
llvm-svn: 280644
|
|
|
|
|
|
| |
test cases for append/insert/assign/replace while we're at it, and fix a similar bug in insert.
llvm-svn: 280643
|
|
|
|
|
|
|
|
|
| |
That is, add build system support for building the OCaml bindings
against preinstalled LLVM libraries. This is important for package
managers such as OPAM, because OCaml libraries need to be built
against a specific OCaml compiler installation.
llvm-svn: 280642
|
|
|
|
|
|
| |
'str' object has no attribute 'decode'.
llvm-svn: 280641
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
flow statement body.
Although it is not explicitly stated in LLVM Coding Standards, LLVM developers
prefer to omit braces around flow control statements with single line body.
For example the following piece of code
```
if (condition)
std::cout << "Hello, world!" << std::endl;
```
is preferred to
```
if (condition) {
std::cout << "Hello, world!" << std::endl;
}
```
So far clang-rename has ignored this. This patch makes clang-rename more
"LLVM-ish".
llvm-svn: 280640
|
|
|
|
|
|
|
| |
For some reason clang-rename fails to rename method of templated class. Add
XFAIL test reproducing the issue.
llvm-svn: 280639
|
|
|
|
|
|
|
|
|
| |
Patch by Eugene Zelenko!
Differential Revision: https://reviews.llvm.org/D24178
Reviewers: omtcyfz
llvm-svn: 280638
|
|
|
|
|
|
|
|
| |
The code to calculate 'UsesRemoved' could be simplified.
As-is, that code is a victim of PR30273:
https://llvm.org/bugs/show_bug.cgi?id=30273
llvm-svn: 280637
|