Summary: Assumption cache's self-updating mechanism does not correctly handle the case when blocks are extracted from the function by the CodeExtractor. As a result function's assumption cache may have stale references to the llvm.assume calls that were moved to the outlined function. This patch fixes this problem by removing extracted llvm.assume calls from the function’s assumption cache.
Reviewers: hfinkel, vsk, fhahn, davidxl, sanjoy
Reviewed By: hfinkel, vsk
Subscribers: llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D57215
llvm-svn: 353500
Summary:
Automatic initialization [1] of __block variables was trampling over the block's
headers after they'd been initialized, which caused self-init usage to crash,
such as here:
typedef struct XYZ { void (^block)(); } *xyz_t;
__attribute__((noinline))
xyz_t create(void (^block)()) {
xyz_t myself = malloc(sizeof(struct XYZ));
myself->block = block;
return myself;
}
int main() {
__block xyz_t captured = create(^(){ (void)captured; });
}
This type of code shouldn't be broken by variable auto-init, even if it's
sketchy.
[1] With -ftrivial-auto-var-init=pattern
<rdar://problem/47798396>
Reviewers: rjmccall, pcc, kcc
Subscribers: jkorous, dexonsmith, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D57797
llvm-svn: 353495
DW_TAG_subprogram DIEs should not be counted in the inlined function statistic. This also addresses the source variables count, as that uses the inlined function count in its calculations.
Differential revision: https://reviews.llvm.org/D57849
llvm-svn: 353491
Summary:
FPCW contains the rounding mode control which we manipulate to implement fp to integer conversion by changing the roudning mode, storing the value to the stack, and then changing the rounding mode back. Because we didn't model FPCW and its dependency chain, other instructions could be scheduled into the middle of the sequence.
This patch introduces the register and adds it as an implciit def of FLDCW and implicit use of the FP binary arithmetic instructions and store instructions. There are more instructions that need to be updated, but this is a good start. I believe this fixes at least the reduced test case from PR40529.
Reviewers: RKSimon, spatel, rnk, efriedma, andrew.w.kaylor
Subscribers: dim, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D57735
llvm-svn: 353489
AArch64 NEON has a bunch of instructions with a "2" suffix that extract
the top half of the source vectors, instead of the bottom half. We have
some DAGCombines to try to take advantage of that. However, they
assumed that any EXTRACT_VECTOR was extracting the high half of the
vector in question.
This issue has apparently existed since the AArch64 backend was merged.
Fixes https://bugs.llvm.org/show_bug.cgi?id=40632 .
Differential Revision: https://reviews.llvm.org/D57862
llvm-svn: 353486
Current interception code does not cover all of the required registers
on Windows for a specific flavor of MOV, so this patch adds cases to
identify the following 5-byte instructions on 64-bit Windows:
mov QWORD PTR [rsp + XX], rdx <- second integer argument
mov QWORD PTR [rsp + XX], r9 <- third integer argument
mov QWORD PTR [rsp + XX], r8 <- fourth integer argument
The instruction for MOV [...] RCX is already covered in the previous
version.
Patch by Matthew McGovern!
Reviewers: rnk
Differential Revision: https://reviews.llvm.org/D57339
llvm-svn: 353483
Summary:
3rd party sysconf interceptor may crash if it's called before unsafe_stack_setup
However pageSize is not useful here. mmap should round up on it's own, SFS_CHECK can be removed.
Reviewers: eugenis, vlad.tsyrklevich
Subscribers: #sanitizers, llvm-commits
Tags: #sanitizers, #llvm
Differential Revision: https://reviews.llvm.org/D57924
llvm-svn: 353481
When a landing pad is calculated in a program that is compiled for micromips
with -fPIC flag, it will point to an even address.
Such an error will cause a segmentation fault, as the instructions in
micromips are aligned on odd addresses. This patch sets the last bit of the
offset where a landing pad is, to 1, which will effectively be an odd
address and point to the instruction exactly.
r344591 fixed this issue for -static compilation.
Patch by Aleksandar Beserminji.
Differential Revision: https://reviews.llvm.org/D57677
llvm-svn: 353480
This patch simply teach BPF driver about the new CPU "v3" introduced in
LLVM backend.
Acked-by: Yonghong Song <yhs@fb.com>
Signed-off-by: Jiong Wang <jiong.wang@netronome.com>
llvm-svn: 353479
Summary:
From runtime side looks it's OK to RoundUpTo to needed alignment as buffer is
going to be RoundUpTo to page size anyway.
Reviewers: eugenis, pcc
Subscribers: #sanitizers
Tags: #sanitizers
Differential Revision: https://reviews.llvm.org/D57866
llvm-svn: 353475
Add a flag to allow symbols to have a wasm import name which differs from the
linker symbol name, allowing the linker to link code using the import_module
attribute.
This is the MC/Object portion of the patch.
Differential Revision: https://reviews.llvm.org/D57632
llvm-svn: 353474
Add a flag to allow symbols to have a wasm import name which differs from the
linker symbol name, allowing the linker to link code using the import_module
attribute.
Differential Revision: https://reviews.llvm.org/D57632
llvm-svn: 353473
This commit teaches InstCombine how to replace an atomicrmw operation
into a simple load atomic.
For a given `atomicrmw <op>`, this is possible when:
1. The ordering of that operation is compatible with a load (i.e.,
anything that doesn't have a release semantic).
2. <op> does not modify the value being stored
Differential Revision: https://reviews.llvm.org/D57854
llvm-svn: 353471
Mostly achieved by assuming that anything that isn't Win or Mac is ELF,
which seems reasonable enough for now.
Differential Revision: https://reviews.llvm.org/D57870
llvm-svn: 353470
This fixes a class of bugs introduced by D44367,
which transforms various cases of icmp (bitcast ([su]itofp X)), Y to icmp X, Y.
If the bitcast is between vector types with a different number of elements,
the current code will produce bad IR along the lines of: icmp <N x i32> ..., <M x i32> <...>.
This patch suppresses the transform if the bitcast changes the number of vector elements.
Patch by: @AndrewScheidecker (Andrew Scheidecker)
Differential Revision: https://reviews.llvm.org/D57871
llvm-svn: 353467
This is part of https://bugs.llvm.org/show_bug.cgi?id=40442.
Vector legalization is implemented for the add/sub overflow opcodes.
UMULO/SMULO are also handled as far as legalization is concerned, but
they don't support vector expansion yet (so no tests for them).
The vector result widening implementation is suboptimal, because it
could result in a legalization loop.
Differential Revision: https://reviews.llvm.org/D57639
llvm-svn: 353464
This patch fixes a bug where clang doesn’t reject union fields of
non-trivial C struct types. For example:
```
// This struct is non-trivial under ARC.
struct S0 {
id x;
};
union U0 {
struct S0 s0; // clang should reject this.
struct S0 s1; // clang should reject this.
};
void test(union U0 a) {
// Previously, both 'a.s0.x' and 'a.s1.x' were released in this
// function.
}
```
rdar://problem/46677858
Differential Revision: https://reviews.llvm.org/D55659
llvm-svn: 353459
Move the (add (umax X, C), -C) --> (usubsat X, C) X86 combine into generic DAGCombiner
First of a number of saturated arithmetic folds that can be moved out of X86-specific code for PR40111.
Differential Revision: https://reviews.llvm.org/D57754
llvm-svn: 353457
Summary:
Deferred diagnostic interface is going to be used for OpenMP device
compilation. Generalized previously existed deferred diagnostic
interface for CUDA to be used with OpenMP and, possibly, other models.
Reviewers: rjmccall, tra
Subscribers: caomhin, cfe-commits, kkwli0
Tags: #clang
Differential Revision: https://reviews.llvm.org/D57908
llvm-svn: 353456
This is pretty much directly ported from SelectionDAG. Doesn't include
the shift by non-constant but known bits version, since there isn't a
globalisel version of computeKnownBits yet.
This shows a disadvantage of targets not specifically which type
should be used for the shift amount. If type 0 is legalized before
type 1, the operations on the shift amount type use the wider type
(which are also less likely to legalize). This can be avoided by
targets specifying legalization actions on type 1 earlier than for
type 0.
llvm-svn: 353455
Sergey Dmitriev