| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
| |
llvm-svn: 325275
|
|
|
|
|
|
|
|
|
|
|
|
| |
There is a latent Windows kernel bug, the exact trigger
conditions are not well understood, which can cause a file
to be correctly written, but unable to be correctly read.
The workaround appears to be simply calling FlushFileBuffers.
Differential Revision: https://reviews.llvm.org/D42925
llvm-svn: 325274
|
|
|
|
|
|
|
| |
Even though "...-wasm" is now the default for wasm, it's still
desirable to test this form.
llvm-svn: 325273
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Many architectures provide SIMD operations (e.g. x86 SSE/AVX, Power AltiVec/VSX,
ARM NEON). It is common that SIMD code implementing the same algorithm, is
written in multiple target-dispatching pieces to optimize for different
architectures or micro-architectures.
The C++ standard proposal P0214 and its extensions cover many common SIMD
operations. By migrating from target-dependent intrinsics to P0214 operations,
the SIMD code can be simplified and pieces for different targets can be unified.
Refer to http://wg21.link/p0214 for introduction and motivation for the
data-parallel standard library.
Subscribers: klimek, aemerson, mgorny, xazax.hun, kristof.beyls, hintonda, cfe-commits
Differential Revision: https://reviews.llvm.org/D42983
llvm-svn: 325272
|
|
|
|
|
|
|
| |
This line is not needed in the test, and breaks Windows testing.
Fixes the test added in r325175.
llvm-svn: 325271
|
|
|
|
|
|
| |
Tests showing missing opportunities to use PACK instructions in cases where we need to truncate to illegal types for stores
llvm-svn: 325270
|
|
|
|
|
|
|
| |
Use the FunctionType of the callee when it's available. It may not be
available for synthetic calls to functions specified by external symbols.
llvm-svn: 325269
|
|
|
|
| |
llvm-svn: 325268
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The reference '&' is missing in the function parameter. If there are
back-to-back optimizations in terms of dag node list like below:
t29: i64,ch = load<LD4[bitcast (%struct.test_t* @test.t to i8*)+12](dereferenceable), zext from i32> t3, t43, undef:i64
t34: i64,ch = load<LD4[bitcast (%struct.test_t* @test.t to i8*)](dereferenceable), zext from i32> t3, t41, undef:i64
The bug will trigger a segfault for the added test case remove_truncate_5.ll:
LLVMSymbolizer: error reading file: No such file or directory
#0 0x000000000241c4d9 (llc+0x241c4d9)
#1 0x000000000241c56a (llc+0x241c56a)
#2 0x000000000241aa50 (llc+0x241aa50)
...
#22 0x0000000000fd5edf (llc+0xfd5edf)
#23 0x00007f0fe03bec05 __libc_start_main (/lib64/libc.so.6+0x21c05)
#24 0x0000000000fd3e69 (llc+0xfd3e69)
...
Segmentation fault
Signed-off-by: Yonghong Song <yhs@fb.com>
llvm-svn: 325267
|
|
|
|
|
|
| |
This is breaking lit tests.
llvm-svn: 325266
|
|
|
|
| |
llvm-svn: 325265
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The following test case causes issue with codegen of __enqueue_block
void (^block)(void) = ^{ callee(id, out); };
enqueue_kernel(queue, 0, ndrange, block);
Clang first does codegen for block expression in the first line and deletes its block info.
Clang then tries to do codegen for the same block expression again for the second line,
and fails because the block info is gone.
The fix is to do normal codegen for both lines. Introduce an API to OpenCL runtime to
record llvm block invoke function and llvm block literal emitted for each AST block
expression, and use the recorded information for generating the wrapper kernel.
The EmitBlockLiteral APIs are cleaned up to minimize changes to the normal codegen
of blocks.
Another minor issue is that some clean up AST expression is generated for block
with captures, which can be stripped by IgnoreImplicit.
Differential Revision: https://reviews.llvm.org/D43240
llvm-svn: 325264
|
|
|
|
| |
llvm-svn: 325263
|
|
|
|
|
|
|
| |
We had redundant tests, but no tests for extra uses or vectors.
'fast' is an overly conservative requirement for these folds.
llvm-svn: 325262
|
|
|
|
|
|
| |
happened.
llvm-svn: 325261
|
|
|
|
| |
llvm-svn: 325260
|
|
|
|
|
|
|
| |
The FunctionType of the callee is always available, even if the Function
of the callee is not. Use that to get the number of fixed parameters.
llvm-svn: 325259
|
|
|
|
|
|
|
| |
Add an empty line after 'liveins:', 'successors:', or '; predecessors:',
the one that ends up to be the last one.
llvm-svn: 325258
|
|
|
|
| |
llvm-svn: 325257
|
|
|
|
|
|
|
|
|
|
| |
considerable use of a type name as an identifier for an object.
Changed identifier names (especially function parameters) to not clash with type names and to follow the proper naming conventions. Use of explicit type names changed to use auto where appropriate. Removed unused parameters that should have never been added in the first place. Minor formatting cleanups.
The changes were mostly mechanical and should have no functional impact.
llvm-svn: 325256
|
|
|
|
|
|
| |
Lowering of formal arguments needs to be aware of vararg functions.
llvm-svn: 325255
|
|
|
|
| |
llvm-svn: 325254
|
|
|
|
| |
llvm-svn: 325253
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This patch adds support for list initialization of proto repeated fields:
```
keys: [1, 2, 3]
```
Reviewers: djasper
Reviewed By: djasper
Subscribers: klimek, cfe-commits
Differential Revision: https://reviews.llvm.org/D43298
llvm-svn: 325252
|
|
|
|
|
|
| |
Prefix it with '; ' to make it more MIR-compatible.
llvm-svn: 325251
|
|
|
|
|
|
| |
The test does not actually connect to any remote targets.
llvm-svn: 325250
|
|
|
|
|
|
| |
Add a fallback definition of getTSCFrequency().
llvm-svn: 325249
|
|
|
|
|
|
|
|
|
|
| |
This is a follow up of:
r325206 - Add NetBSD syscall hooks skeleton in sanitizers
Sponsored by <The NetBSD Foundation>
llvm-svn: 325248
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The variable name 'AllowReassociate' is a lie at this point because
it's set to 'isFast()' which is more than the 'reassoc' FMF after
rL317488.
In D41286, we showed that this transform may be valid even with strict
math by brute force checking every 32-bit float result.
There's a potential problem here because we're replacing with a tan()
libcall rather than a hypothetical LLVM tan intrinsic. So we might
set errno when we should be guaranteed not to do that. But that's
independent of this change.
llvm-svn: 325247
|
|
|
|
|
|
| |
Sponsored by <The NetBSD Foundation>
llvm-svn: 325246
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
NetBSD ships now with netbsd_syscall_hooks.h and requires support
for TSan specific features to be enabled.
This is follow up of:
D42048: Add NetBSD syscall hooks skeleton in sanitizers
Sponsored by <The NetBSD Foundation>
llvm-svn: 325245
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
In LLVM, 't' selects a floating-point/SIMD register and only supports
32-bit values. This is appropriately documented in the LLVM Language
Reference Manual. However, this behaviour diverges from that of GCC, where
't' selects the s0-s31 registers and its qX and dX variants depending on
additional operand modifiers (q/P).
For example, the following C code:
#include <arm_neon.h>
float32x4_t a, b, x;
asm("vadd.f32 %0, %1, %2" : "=t" (x) : "t" (a), "t" (b))
results in the following assembly if compiled with GCC:
vadd.f32 s0, s0, s1
whereas LLVM will show "error: couldn't allocate output register for
constraint 't'", since a, b, x are 128-bit variables, not 32-bit.
This patch extends the use of 't' to mean that of GCC, thus allowing
selection of the lower Q vector regs and their D/S variants. For example,
the earlier code will now compile as:
vadd.f32 q0, q0, q1
This behaviour still differs from that of GCC but I think it is actually
more correct, since LLVM picks up the right register type based on the
datatype of x, while GCC would need an extra operand modifier to achieve
the same result, as follows:
asm("vadd.f32 %q0, %q1, %q2" : "=t" (x) : "t" (a), "t" (b))
Since this is only an extension of functionality, existing code should not
be affected by this change. Note that operand modifiers q/P are already
supported by LLVM, so this patch should suffice to support inline
assembly with constraint 't' originally built for GCC.
Reviewers: grosbach, rengolin
Reviewed By: rengolin
Subscribers: rogfer01, efriedma, olista01, aemerson, javed.absar, eraman, kristof.beyls, llvm-commits
Differential Revision: https://reviews.llvm.org/D42962
llvm-svn: 325244
|
|
|
|
|
|
|
|
| |
PACKUS vXi32-vXi8 saturated truncation
We can use PACKSS/PACKUS to saturate each stage of the chain: PACKSSDW down to [-32768,32767] and then PACKUSWB to [0,255].
llvm-svn: 325243
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: And remove -enable-snippets flag.
Reviewers: hokein, ioeric, sammccall
Reviewed By: ioeric
Subscribers: klimek, jkorous-apple, cfe-commits
Differential Revision: https://reviews.llvm.org/D43229
llvm-svn: 325242
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: Enabling memory sanitiser for X86_64 arch only. To match the sanitiser counterpart.
Patch by: David CARLIER
Reviewers: krytarowski
Reviewed By: krytarowski
Subscribers: dim, emaste, cfe-commits
Differential Revision: https://reviews.llvm.org/D43148
llvm-svn: 325241
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
- Enabling the build.
- Using assembly for the cpuid parts.
- Using thr_self FreeBSD call to get the thread id
Patch by: David CARLIER
Reviewers: dberris, rnk, krytarowski
Reviewed By: dberris, krytarowski
Subscribers: emaste, stevecheckoway, nglevin, srhines, kubamracek, dberris, mgorny, krytarowski, llvm-commits, #sanitizers
Differential Revision: https://reviews.llvm.org/D43278
llvm-svn: 325240
|
|
|
|
| |
llvm-svn: 325239
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: Similarly to the GNU driver version, adding proper compile and linker flags.
Patch by: David CARLIER
Reviewers: vitalybuka, krytarowski, dberris
Reviewed By: krytarowski, dberris
Subscribers: emaste, dberris, cfe-commits
Differential Revision: https://reviews.llvm.org/D43279
llvm-svn: 325238
|
|
|
|
| |
llvm-svn: 325237
|
|
|
|
| |
llvm-svn: 325236
|
|
|
|
|
|
|
|
|
|
| |
PACKSS vXi32-vXi8 saturated truncation
We can use PACKSS to saturate each stage of the chain: PACKSSDW down to [-32768,32767] and then PACKSSWB to [-128,127].
PACKUS is a little trickier and will be handled in a separate patch.
llvm-svn: 325235
|
|
|
|
|
|
|
|
|
|
| |
debug info metadata
... when generating DWARF.
Differential Revision: https://reviews.llvm.org/D43304
llvm-svn: 325234
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
As a consequence, all LSP operations are now handled asynchronously,
i.e. they never block the main processing thread. However, if
-run-synchronously flag is specified, clangd still runs everything on
the main thread.
Reviewers: sammccall, ioeric, hokein
Reviewed By: sammccall, ioeric
Subscribers: klimek, jkorous-apple, cfe-commits
Differential Revision: https://reviews.llvm.org/D43227
llvm-svn: 325233
|
|
|
|
|
|
|
|
|
|
|
|
| |
TargetLowering::SimplifyDemandedVectorElts
This is mainly a move of simplifyShuffleOperands from DAGCombiner::visitVECTOR_SHUFFLE to create a more general purpose TargetLowering::SimplifyDemandedVectorElts implementation.
Further features can be moved/added in future patches.
Differential Revision: https://reviews.llvm.org/D42896
llvm-svn: 325232
|
|
|
|
|
|
|
|
| |
This adds f16 VCMP match rules and fixes the test cases.
Differential Revision: https://reviews.llvm.org/D43291
llvm-svn: 325228
|
|
|
|
|
|
| |
It caused fails on some buildbots.
llvm-svn: 325227
|
|
|
|
| |
llvm-svn: 325226
|
|
|
|
| |
llvm-svn: 325225
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Analysis of fails in the case of out of memory errors can be tricky on
Windows. Such error emerges at the point where memory allocation function
fails, but manifests itself when null pointer is used. These two points
may be distant from each other. Besides, next runs may not exhibit
allocation error.
Usual programming practice does not require checking result of 'operator
new' because it throws 'std::bad_alloc' in the case of allocation error.
However, LLVM is usually built with exceptions turned off, so 'new' can
return null pointer. This change installs custom new handler, which causes
fatal error in the case of out of memory. The handler is installed
automatically prior to call to 'main' during construction of a static
object defined in 'lib/Support/ErrorHandling.cpp'. If the application does
not use this file, the handler may be installed manually by a call to
'llvm::install_out_of_memory_new_handler', declared in
'include/llvm/Support/ErrorHandling.h".
There are calls to C allocation functions, malloc, calloc and realloc.
They are used for interoperability with C code, when allocated object has
variable size and when it is necessary to avoid call of constructors. In
many calls the result is not checked against null pointer. To simplify
checks, new functions are defined in the namespace 'llvm' with the
same names as these C function. These functions produce fatal error if
allocation fails. User should use 'llvm::malloc' instead of 'std::malloc'
in order to use the safe variant. This change replaces 'std::malloc'
in the cases when the result of allocation function is not checked against
null pointer.
Finally, there are plain C code, that uses malloc and similar functions. If
the result is not checked, assert statements are added.
Differential Revision: https://reviews.llvm.org/D43010
llvm-svn: 325224
|
|
|
|
| |
llvm-svn: 325223
|