The following code pattern:
mov %rax, %rcx
test %rax, %rax
%rax = ....
je throw_npe
mov(%rcx), %r9
mov(%rax), %r10
gets transformed into the following incorrect code after implicit null check pass:
mov %rax, %rcx
%rax = ....
faulting_load_op("movl (%rax), %r10", throw_npe)
mov(%rcx), %r9
For implicit null check pass, if the register that is checked for null value (ie, the register used in the 'test' instruction) is written into before the condition jump, we should avoid doing the optimization.
Patch by Surya Kumari Jangala!
Differential Revision: https://reviews.llvm.org/D48627
Reviewed By: skatkov
llvm-svn: 336241
merged function definitions; also merge functions with deduced return
types.
This seems like two independent fixes, but unfortunately they are hard
to separate because it's challenging to reliably test either one of them
without also testing the other.
A complication arises with deduced return type support: we need the type
of the function in order to know how to merge it, but we can't load the
actual type of the function because it might reference an entity
declared within the function (and we need to have already merged the
function to correctly merge that entity, which we would need to do to
determine if the function types match). So we instead compare the
declared function type when merging functions, and defer loading the
actual type of a function with a deduced type until we've finished
loading and merging the function.
This reverts r336175, reinstating r336021, with one change (for PR38015):
we look at the TypeSourceInfo of the first-so-far declaration of each
function when considering whether to merge two functions. This works
around a problem where the calling convention in the TypeSourceInfo for
subsequent redeclarations may not match if it was implicitly adjusted.
llvm-svn: 336240
If a function has multiple format_arg attributes, clang only considers
the first it finds (because AttributeLists are in reverse order, not
necessarily the textually first) and ignores all others.
Loop over all FormatArgAttr to print warnings for all declared
format_arg attributes.
For instance, libintl's ngettext (select plural or singular version of
format string) has two __format_arg__ attributes.
Differential Revision: https://reviews.llvm.org/D48734
llvm-svn: 336239
The constexpr evaluator was erroring out because these templates weren't
defined. Despite being used in a discarded statement, we still need to constexpr
evaluate them, which means that we need to instantiate them. Fixes PR37585.
Differential revision: https://reviews.llvm.org/D48322
llvm-svn: 336233
Existing code always allocates for on the declarator's attribute pool,
but sometimes adds it to the declspec. This patch ensures that the
correct pool is used.
Discovered while testing: https://reviews.llvm.org/D48788
llvm-svn: 336225
D48768 may turn some of these into shifts.
Reviewers: spatel
Reviewed By: spatel
Subscribers: spatel, RKSimon, llvm-commits, craig.topper
Differential Revision: https://reviews.llvm.org/D48767
llvm-svn: 336224
Summary:
The C interceptors were using `SIZE_T` defined in the interception library as
a `__sanitizer::uptr`. On some 32-bit platforms, this lead to the following
warning:
```
warning: declaration of ‘void* malloc(SIZE_T)’ conflicts with built-in declaration ‘void* malloc(unsigned int)’ [-Wbuiltin-declaration-mismatch]
INTERCEPTOR_ATTRIBUTE void *malloc(SIZE_T size) {
```
`__sanitizer::uptr` is indeed defined as an `unsigned long` on those.
So just include `stddef.h` and use `size_t` instead.
Reviewers: alekseyshl
Reviewed By: alekseyshl
Subscribers: delcypher, llvm-commits, #sanitizers
Differential Revision: https://reviews.llvm.org/D48885
llvm-svn: 336221
This happened during a recent refactor. toStringRefArray() returns
a vector<StringRef>, which was being implicitly converted to an
ArrayRef<StringRef>, and then the vector was immediately being
destroyed, so the ArrayRef<> was losing its backing storage.
Fix this by making sure the vector gets permanent storage.
llvm-svn: 336219
This patch adds a new token type specifically for (%dx). We will now always create this token when we parse (%dx). After all operands have been parsed, if the mnemonic is in/out we'll morph this token to a regular register token. Otherwise we keep it as the special DX token which won't match any instructions.
This removes the need for passing Mnemonic through the parsing functions. It also seems closer to gas where when its used on the wrong instruction it just gets diagnosed as an invalid operand rather than a bad memory address.
llvm-svn: 336218
This might make the error message added in r335668 unneeded, but I'm not sure yet.
The check for RIP is technically unnecessary since RIP is in GR64, but that fact is kind of surprising so be explicit.
llvm-svn: 336217
As the test diffs show, the current users of getBinOpIdentity()
are InstCombine and Reassociate. SLP vectorizer is a candidate
for using this functionality too (D28907).
The InstCombine shuffle improvements are part of the planned
enhancements noted in D48830.
InstCombine actually has several other uses of getBinOpIdentity()
via SimplifyUsingDistributiveLaws(), but we don't call that for
any FP ops. Fixing that might be another part of removing the
custom reassociation in InstCombine that is only done for fadd+fmul.
llvm-svn: 336215
Summary:
In conjunction with the clang side change D48833, this will enable Scudo on
PPC64. I tested `check-scudo` on a powerpc64le box and everything passes.
Reviewers: eugenis, alekseyshl
Reviewed By: alekseyshl
Subscribers: mgorny, delcypher, #sanitizers, llvm-commits
Differential Revision: https://reviews.llvm.org/D48834
llvm-svn: 336213
r336120 resulted in falling back to SelectionDAG more often due to the G_STORE
MMOs not matching the vreg size. This fixes that by explicitly any-extending the
value.
llvm-svn: 336209
Unpredicated FP-multiply of SVE vector with a vector-element given by
vector[index], for example:
fmul z0.s, z1.s, z2.s[0]
which performs an unpredicated FP-multiply of all 32-bit elements in
'z1' with the first element from 'z2'.
This patch adds restricted register classes for SVE vectors:
ZPR_3b (only z0..z7 are allowed) - for indexed vector of 16/32-bit elements.
ZPR_4b (only z0..z15 are allowed) - for indexed vector of 64-bit elements.
Reviewers: rengolin, fhahn, SjoerdMeijer, samparker, javed.absar
Reviewed By: fhahn
Differential Revision: https://reviews.llvm.org/D48823
llvm-svn: 336205
Summary:
Scudo works on PPC64 as is, so mark the architecture as supported for it. This
will also require a change to config-ix.cmake on the compiler-rt side.
Update the tests accordingly.
Reviewers: eugenis, alekseyshl
Reviewed By: alekseyshl
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D48833
llvm-svn: 336202
Summary: The new API allows to find a list of compile units related to target/module.
Reviewers: aprantl, clayborg
Reviewed By: aprantl
Subscribers: jingham, lldb-commits
Differential Revision: https://reviews.llvm.org/D48801
llvm-svn: 336200
This is the last significant change suggested in PR37806:
https://bugs.llvm.org/show_bug.cgi?id=37806#c5
...though there are several follow-ups noted in the code comments
in this patch to complete this transform.
It's possible that a binop feeding a select-shuffle has been eliminated
by earlier transforms (or the code was just written like this in the 1st
place), so we'll fail to match the patterns that have 2 binops from:
D48401,
D48678,
D48662,
D48485.
In that case, we can try to materialize identity constants for the remaining
binop to fill in the "ghost" lanes of the vector (where we just want to pass
through the original values of the source operand).
I added comments to ConstantExpr::getBinOpIdentity() to show planned follow-ups.
For now, we only handle the 5 commutative integer binops (add/mul/and/or/xor).
Differential Revision: https://reviews.llvm.org/D48830
llvm-svn: 336196
With a view to support parallel operations that have their results
stored to memory, refactor the consecutive access helper out so it
could support stores instructions.
Differential Revision: https://reviews.llvm.org/D48872
llvm-svn: 336195
This adds the following system registers:
- RAS registers,
- MPAM registers,
- Activitiy monitor registers,
- Trace Extension registers,
- Timing insensitivity of data processing instructions,
- Enhanced Support for Nested Virtualization.
Differential Revision: https://reviews.llvm.org/D48871
llvm-svn: 336193
Sam McCall