| Commit message (Collapse) | Author | Age | Files | Lines |
| ... | |
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
SVE overloads the AArch64 PSTATE condition flags and introduces
a set of condition code aliases for the assembler. The
details are described in section 2.2 of the architecture
reference manual supplement for SVE.
In short:
SVE alias => AArch64 name
--------------------------
NONE => EQ
ANY => NE
NLAST => HS
LAST => LO
FIRST => MI
NFRST => PL
PMORE => HI
PLAST => LS
TCONT => GE
TSTOP => LT
Reviewers: rengolin, fhahn, SjoerdMeijer, samparker, javed.absar
Reviewed By: fhahn
Differential Revision: https://reviews.llvm.org/D48869
llvm-svn: 336245
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Can happen when getConstructorName is called on invalid decls,
specifically the ones that do not have the injected class name.
Reviewers: bkramer, rsmith
Reviewed By: rsmith
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D48880
llvm-svn: 336244
|
| |
|
|
| |
llvm-svn: 336243
|
| |
|
|
| |
llvm-svn: 336242
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D48650
llvm-svn: 336238
|
| |
|
|
| |
llvm-svn: 336237
|
| |
|
|
|
|
| |
Loads and stores less than 64-bits are already atomic, this adds support for a special case thereof. This needs to be expanded.
llvm-svn: 336236
|
| |
|
|
| |
llvm-svn: 336235
|
| |
|
|
| |
llvm-svn: 336234
|
| |
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
| |
llvm-svn: 336232
|
| |
|
|
|
|
| |
places we hardcode it.
llvm-svn: 336231
|
| |
|
|
| |
llvm-svn: 336230
|
| |
|
|
| |
llvm-svn: 336229
|
| |
|
|
|
|
| |
One implementation of this ought to be enough for everyone.
llvm-svn: 336228
|
| |
|
|
|
|
| |
Vectorization can create them.
llvm-svn: 336227
|
| |
|
|
|
|
| |
pasted. NFC
llvm-svn: 336226
|
| |
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
| |
llvm-svn: 336223
|
| |
|
|
|
|
| |
definitions
llvm-svn: 336222
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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 adds coverage for a planned enhancement for ConstantExpr::getBinOpIdentity() noted in D48830.
llvm-svn: 336220
|
| |
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
| |
llvm-svn: 336216
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
| |
llvm-svn: 336214
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
| |
Added missing headers.
llvm-svn: 336212
|
| |
|
|
| |
llvm-svn: 336211
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The variants added in this patch are:
- Predicated Complex floating point ADD with rotate, e.g.
fcadd z0.h, p0/m, z0.h, z1.h, #90
- Predicated Complex floating point MLA with rotate, e.g.
fcmla z0.h, p0/m, z1.h, z2.h, #180
- Unpredicated Complex floating point MLA with rotate (indexed operand), e.g.
fcmla z0.h, p0/m, z1.h, z2.h[0], #180
Reviewers: rengolin, fhahn, SjoerdMeijer, samparker, javed.absar
Reviewed By: fhahn
Differential Revision: https://reviews.llvm.org/D48824
llvm-svn: 336210
|
| |
|
|
|
|
|
|
|
|
| |
unselectable stores.
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
|
| |
|
|
| |
llvm-svn: 336208
|
| |
|
|
|
|
| |
Suggested in review for D48698.
llvm-svn: 336207
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: Now this command uses SB API instead of HandleCommand.
Reviewers: aprantl, clayborg
Reviewed By: aprantl, clayborg
Subscribers: ki.stfu, eraman, lldb-commits
Differential Revision: https://reviews.llvm.org/D48802
llvm-svn: 336206
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The patch includes support for the following instructions:
ABS z0.h, p0/m, z0.h
NEG z0.h, p0/m, z0.h
(S|U)XTB z0.h, p0/m, z0.h
(S|U)XTB z0.s, p0/m, z0.s
(S|U)XTB z0.d, p0/m, z0.d
(S|U)XTH z0.s, p0/m, z0.s
(S|U)XTH z0.d, p0/m, z0.d
(S|U)XTW z0.d, p0/m, z0.d
llvm-svn: 336204
|
| |
|
|
| |
llvm-svn: 336203
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
| |
llvm-svn: 336201
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
| |
Minor follow up for r336197
"[ELF] - Add support for '||' and '&&' in linker scripts."
llvm-svn: 336199
|
| |
|
|
|
|
| |
Now that D45806 has landed, we can re-enable support for MIN_SIGNED_VALUE in the sdiv by pow2-constant code
llvm-svn: 336198
|
| |
|
|
|
|
|
| |
This is https://bugs.llvm.org//show_bug.cgi?id=37976,
we had no support, but seems someone faced it.
llvm-svn: 336197
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|