| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
|
|
| |
PACKUSWB converts Signed word to Unsigned byte, (the same about DW) and it can't be used for umin+truncate pattern.
AVX-512 VPMOVUS* instructions fit the pattern since they convert Unsigned to Unsigned.
See https://llvm.org/bugs/show_bug.cgi?id=31773
Differential Revision: https://reviews.llvm.org/D29196
llvm-svn: 293431
|
| |
|
|
|
|
|
|
| |
llvm/test/CodeGen/AArch64/GlobalISel/gisel-abort.ll.
Unsupported target might be induced if default target is neither macho nor elf. (e.g. *-win32)
llvm-svn: 293430
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Add a simple example to update the documentation on how the packing
transformation is implemented.
Reviewed-by: Tobias Grosser <tobias@grosser.es>,
Michael Kruse <llvm@meinersbur.de>
Differential Revision: https://reviews.llvm.org/D28021
llvm-svn: 293429
|
| |
|
|
| |
llvm-svn: 293428
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Add limited (i8/i16/i32/i64) argument lowering support to the IRTranslator.
Inspired by commit 289940.
Reviewers: t.p.northover, qcolombet, ab, zvi, rovka
Reviewed By: rovka
Subscribers: dberris, rovka, kristof.beyls, llvm-commits
Differential Revision: https://reviews.llvm.org/D28987
llvm-svn: 293427
|
| |
|
|
|
|
|
|
|
|
| |
here. NFC.
Simple refactoring while prepping a port to the new PM.
Differential Revision: https://reviews.llvm.org/D29249
llvm-svn: 293426
|
| |
|
|
|
|
|
|
|
|
| |
formatting that has evolved here over the past years prior to making
somewhat invasive changes to thread new PM support through the business
logic.
Differential Revision: https://reviews.llvm.org/D29248
llvm-svn: 293425
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This arranges the static helpers in an order where they are defined
prior to their use to avoid the need of forward declarations, and
collect the core pass components at the bottom below their helpers.
This also folds one trivial function into the pass itself. Factoring
this 'runImpl' was an attempt to help porting to the new pass manager,
however in my attempt to begin this port in earnest it turned out to not
be a substantial help. I think it will be easier to factor things
without it.
This is an NFC change and does a minimal amount of edits over all.
Subsequent NFC cleanups will normalize the formatting with clang-format
and improve the basic doxygen commenting.
Differential Revision: https://reviews.llvm.org/D29247
llvm-svn: 293424
|
| |
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D29230
llvm-svn: 293423
|
| |
|
|
|
|
|
|
|
| |
Update the headers, so we can change the dllexports to dllimport when
defining SANITIZER_IMPORT_INTERFACE.
Differential Revision: https://reviews.llvm.org/D29052
llvm-svn: 293422
|
| |
|
|
|
|
| |
It's operation already exists manually in many places without using the method.
llvm-svn: 293421
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
I modify clang driver for windows to include:
"-wholearchive:asan_dynamic_runtime_thunk", so all object files in the
static library: asan_dynamic_runtime_thunk are considered by the linker.
This is necessary, because some object files only include linker pragmas,
and doesn't resolve any symbol. If we don't include that flag, the
linker will ignore them, and won't read the linker pragmas.
Differential Revision: https://reviews.llvm.org/D29159
llvm-svn: 293420
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In this diff, I define a general macro for defining weak functions
with a default implementation: "SANITIZER_INTERFACE_WEAK_DEF()".
This way, we simplify the implementation for different platforms.
For example, we cannot define weak functions on Windows, but we can
use linker pragmas to create an alias to a default implementation.
All of these implementation details are hidden in the new macro.
Also, as I modify the name for exported weak symbols on Windows, I
needed to temporarily disable "dll_host" test for asan, which checks
the list of functions included in asan_win_dll_thunk.
Differential Revision: https://reviews.llvm.org/D28596
llvm-svn: 293419
|
| |
|
|
| |
llvm-svn: 293418
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Adds the following instructions:
* mfpmr
* mtpmr
* icblc
* icblq
* icbtls
Fix the scheduling for mtspr on e5500, which uses CFX0, instead of
SFX0/SFX1 as on e500mc.
Addresses PR 31538.
Differential Revision: https://reviews.llvm.org/D29002
llvm-svn: 293417
|
| |
|
|
|
|
| |
information from a PCH/module file.
llvm-svn: 293416
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Oops... r293393 started calling ReadSignature in
ModuleManager::addModule even when there was no ExpectedSignature.
Whether or not this would have a measurable performance impact (I
spotted this by inspection, and ReadSignature should be fairly fast), we
might as well get what we can. Add an extra check against
ExpectedSignature to avoid the hit.
llvm-svn: 293415
|
| |
|
|
|
|
| |
The type system requires that the number of vector elements should fit in 32-bits so this should be safe.
llvm-svn: 293414
|
| |
|
|
|
|
|
|
| |
of EXTRACT_SUBVECTOR.
The type system already requires that the number of vector elements must fit in 32-bits so an index should as well. Even if the type of the index were larger all we care about is that the constant index can fit in 64-bits so that we can call getZExtValue.
llvm-svn: 293413
|
| |
|
|
|
|
| |
trying to use getConstantOperandVal.
llvm-svn: 293412
|
| |
|
|
| |
llvm-svn: 293411
|
| |
|
|
| |
llvm-svn: 293410
|
| |
|
|
| |
llvm-svn: 293409
|
| |
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D29141
llvm-svn: 293408
|
| |
|
|
|
|
|
|
| |
It is, in fact, unused. Found while reviewing Danny's new
SSAUpdater and porting passes to it to see how the new API
looked like.
llvm-svn: 293407
|
| |
|
|
|
|
|
|
| |
Most flags were already initialized by the TargetOptions constructor but
we missed out on one. Also, simplify the constructor by using field
initializers when possible.
llvm-svn: 293406
|
| |
|
|
|
|
|
| |
appendCallAsync, which all RPC call functions ultimately build on, will call
abandonAllPendingResponses on channel error. These extra calls are redundant.
llvm-svn: 293405
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Zero-initialize ModuleFile members directly in the class definition, and
move the (now uninteresting) constructor into the class definition.
There were a few members that weren't being initialized at all. I
zero-initialized them for consistency, but it's likely that they were
somehow initialized before their first use; i.e., there's likely no
functionality change here.
llvm-svn: 293404
|
| |
|
|
|
|
| |
are XORs.
llvm-svn: 293403
|
| |
|
|
|
|
|
|
| |
to the AND are XORs.
The matching code tries to canonicalize XOR to the left, but if there are two XORs and only one is a vnot, this canonicalization can prevent matching.
llvm-svn: 293402
|
| |
|
|
| |
llvm-svn: 293401
|
| |
|
|
|
|
|
|
|
| |
Invert the main branch in ModuleManager::addModule to return early and
reduce indentation, and clean up a bunch of logic as a result. I split
out a function called updateModuleImports to avoid triggering code
duplication.
llvm-svn: 293400
|
| |
|
|
|
|
|
|
|
|
| |
I don't have a testcase for this (and I'm not sure if it's an observable
bug), but it seems obviously wrong that ModuleManager::removeModules is
failing to clean up deleted modules from ModuleFile::Imports. See the
code in ModuleManager::addModule that inserts into ModuleFile::Imports;
we need the inverse operation.
llvm-svn: 293399
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
ModuleManager::removeModules always deletes a tail of the
ModuleManager::Chain. Change the API to enforce that so that we can
simplify the code inside.
There's no real functionality change, although there's a slight
performance hack to loop to the First deleted module instead of the
final module in the chain (skipping the about-to-be-deleted tail).
Also document something suspicious: we fail to clean deleted modules out
of ModuleFile::Imports.
llvm-svn: 293398
|
| |
|
|
| |
llvm-svn: 293397
|
| |
|
|
| |
llvm-svn: 293396
|
| |
|
|
|
|
|
| |
Use std::unique_ptr to clarify the ownership of the ModuleFile instances in
ModuleManager.
llvm-svn: 293395
|
| |
|
|
|
|
|
|
| |
Hide the pointer indirection in ModuleManager::begin, ModuleManager::end,
ModuleManager::rbegin, and ModuleManager::rend. Besides tidying up the call
sites, this is preparation for making ownership of ModuleFile explicit.
llvm-svn: 293394
|
| |
|
|
|
|
|
|
|
|
|
|
| |
The main point is to move the delete-the-new-module logic into the same block
that creates it, so I can simplify the memory management in a follow-up, but I
think it's clearer to use use a checkSignature helper here anyway.
There is a minor functionality change: we now scan ahead to pull the signature
out of the control block *only* if this is a new ModuleFile. For old ones,
ASTReader::ReadControlBlock will have already read the signature.
llvm-svn: 293393
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Remove dependency on the proc (/proc) filesystem, which is optional.
KERN_PROC_PATHNAME is available in NetBSD-current and will land NetBSD 8.0.
Older stable versions of NetBSD will not be supported.
Sponsored by <The NetBSD Foundation>
Reviewers: emaste, joerg, labath, clayborg
Reviewed By: clayborg
Subscribers: #lldb
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D29089
llvm-svn: 293392
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Real-Time Signals are available in NetBSD-current and will land NetBSD 8.0.
Older stable versions of NetBSD will not be supported.
Sponsored by <The NetBSD Foundation>
Reviewers: labath, joerg, clayborg, emaste
Reviewed By: labath, clayborg, emaste
Subscribers: #lldb
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D29091
llvm-svn: 293391
|
| |
|
|
| |
llvm-svn: 293390
|
| |
|
|
|
|
| |
systems seem to require it
llvm-svn: 293389
|
| |
|
|
| |
llvm-svn: 293388
|
| |
|
|
| |
llvm-svn: 293387
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
non-consecutive (jumbled) way.
The jumbled scalar loads will be sorted while building the tree and these accesses will be marked to generate shufflevector after the vectorized load with proper mask.
Reviewers: hfinkel, mssimpso, mkuper
Differential Revision: https://reviews.llvm.org/D26905
Change-Id: I9c0c8e6f91a00076a7ee1465440a3f6ae092f7ad
llvm-svn: 293386
|
| |
|
|
|
|
|
|
|
|
|
| |
The symbols _end, end, _etext, etext, _edata, edata and __ehdr_start
refer to positions in the file and are therefore not absolute. Making
them absolute was on unfortunate cargo cult of what bfd was doing.
Changing the symbols allows for pc relocations to them to be resolved,
which should fix the wine build.
llvm-svn: 293385
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Support for barrier synchronization between a subset of threads
in a CTA through one of sixteen explicitly specified barriers.
These intrinsics are not directly exposed in CUDA but are
critical for forthcoming support of OpenMP on NVPTX GPUs.
The intrinsics allow the synchronization of an arbitrary
(multiple of 32) number of threads in a CTA at one of 16
distinct barriers. The two intrinsics added are as follows:
call void @llvm.nvvm.barrier.n(i32 10)
waits for all threads in a CTA to arrive at named barrier #10.
call void @llvm.nvvm.barrier(i32 15, i32 992)
waits for 992 threads in a CTA to arrive at barrier #15.
Detailed description of these intrinsics are available in the PTX manual.
http://docs.nvidia.com/cuda/parallel-thread-execution/#parallel-synchronization-and-communication-instructions
Reviewers: hfinkel, jlebar
Differential Revision: https://reviews.llvm.org/D17657
llvm-svn: 293384
|
| |
|
|
| |
llvm-svn: 293383
|
| |
|
|
|
|
| |
misc-unused-using-decls NFC
llvm-svn: 293382
|