| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
| |
I had missed that massive.mir also needed updating.
llvm-svn: 372303
|
|
|
|
|
|
| |
Avoids repeating the size.
llvm-svn: 372302
|
|
|
|
| |
llvm-svn: 372301
|
|
|
|
|
|
|
|
| |
Correct more uses of 0 instead of LLDB_INVALID_SIGNAL_NUMBER.
Differential Revision: https://reviews.llvm.org/D67727
llvm-svn: 372300
|
|
|
|
|
|
|
|
| |
Similar to the resolution of gcc PR71876.
Nobody uses them or needs the [-Wincomplete-setjmp-declaration]
diagnostic.
llvm-svn: 372299
|
|
|
|
|
|
|
|
|
|
|
|
| |
Reviewers: arsenm, pendingchaos, rampitec, nhaehnle, vpykhtin
Subscribers: kzhuravl, jvesely, wdng, yaxunl, dstuttard, tpr, t-tye, hiraditya, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D65901
llvm-svn: 372298
|
|
|
|
| |
llvm-svn: 372297
|
|
|
|
|
|
| |
These have the same operand structure as the non-t buffer operations.
llvm-svn: 372296
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The clang intrinsic __builtin_preserve_access_index() currently
has signature:
const void * __builtin_preserve_access_index(const void * ptr)
This may cause compiler warning when:
- parameter type is "volatile void *" or "const volatile void *", or
- the assign-to type of the intrinsic does not have "const" qualifier.
Further, this signature does not allow dereference of the
builtin result pointer as it is a "const void *" type, which
adds extra step for the user to do type casting.
Let us change the signature to:
PointerT __builtin_preserve_access_index(PointerT ptr)
such that the result and argument types are the same.
With this, directly dereferencing the builtin return value
becomes possible.
Differential Revision: https://reviews.llvm.org/D67734
llvm-svn: 372294
|
|
|
|
|
|
|
|
|
| |
This needs special handling due to some subtargets that have a
nonstandard register layout for f16 vectors
Also reject some illegal types on other targets.
llvm-svn: 372293
|
|
|
|
| |
llvm-svn: 372292
|
|
|
|
| |
llvm-svn: 372291
|
|
|
|
| |
llvm-svn: 372290
|
|
|
|
|
|
| |
Images should always have 2 consecutive, mandatory SGPR arguments.
llvm-svn: 372289
|
|
|
|
| |
llvm-svn: 372288
|
|
|
|
|
|
|
| |
The assert would fail if there was a dead def of a subregister if
there was a previous use of a different subregister.
llvm-svn: 372287
|
|
|
|
|
|
| |
The scalar versions were only introduced in gfx9.
llvm-svn: 372286
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Encode them directly as an imm argument to G_INTRINSIC*.
Since now intrinsics can now define what parameters are required to be
immediates, avoid using registers for them. Intrinsics could
potentially want a constant that isn't a legal register type. Also,
since G_CONSTANT is subject to CSE and legalization, transforms could
potentially obscure the value (and create extra work for the
selector). The register bank of a G_CONSTANT is also meaningful, so
this could throw off future folding and legalization logic for AMDGPU.
This will be much more convenient to work with than needing to call
getConstantVRegVal and checking if it may have failed for every
constant intrinsic parameter. AMDGPU has quite a lot of intrinsics wth
immarg operands, many of which need inspection during lowering. Having
to find the value in a register is going to add a lot of boilerplate
and waste compile time.
SelectionDAG has always provided TargetConstant for constants which
should not be legalized or materialized in a register. The distinction
between Constant and TargetConstant was somewhat fuzzy, and there was
no automatic way to force usage of TargetConstant for certain
intrinsic parameters. They were both ultimately ConstantSDNode, and it
was inconsistently used. It was quite easy to mis-select an
instruction requiring an immediate. For SelectionDAG, start emitting
TargetConstant for these arguments, and using timm to match them.
Most of the work here is to cleanup target handling of constants. Some
targets process intrinsics through intermediate custom nodes, which
need to preserve TargetConstant usage to match the intrinsic
expectation. Pattern inputs now need to distinguish whether a constant
is merely compatible with an operand or whether it is mandatory.
The GlobalISelEmitter needs to treat timm as a special case of a leaf
node, simlar to MachineBasicBlock operands. This should also enable
handling of patterns for some G_* instructions with immediates, like
G_FENCE or G_EXTRACT.
This does include a workaround for a crash in GlobalISelEmitter when
ARM tries to uses "imm" in an output with a "timm" pattern source.
llvm-svn: 372285
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This was always the intended behavior, but had not been
implemented. This ordering is important for Emscripten when generating
.mem files while compiling to JS, since only zeros at the end of
initialized memory can be dropped.
Fixes https://github.com/emscripten-core/emscripten/issues/8999
Reviewers: sbc100
Subscribers: dschuff, jgravelle-google, aheejin, sunfish, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D67736
llvm-svn: 372284
|
|
|
|
| |
llvm-svn: 372283
|
|
|
|
|
|
|
|
| |
Patch by Diego Treviño!
Differential Revision: https://reviews.llvm.org/D66263
llvm-svn: 372282
|
|
|
|
|
|
|
|
|
|
|
| |
Due to usage of an uninitialized fields, we end up with
a Conditional jump or move depends on uninitialised value
Fixes https://bugs.llvm.org/show_bug.cgi?id=40547
Commited on behalf of Martin Liska <mliska@suse.cz>
llvm-svn: 372281
|
|
|
|
|
|
| |
Found my msan buildbot & pointed out by Nico Weber - thanks Nico!
llvm-svn: 372280
|
|
|
|
|
|
|
|
|
|
|
|
| |
Make the method MachOUniversalBinary::getObjectForArch return MachOUniversalBinary::ObjectForArch
and add helper methods MachOUniversalBinary::getMachOObjectForArch, MachOUniversalBinary::getArchiveForArch
for those who explicitly expect to get a MachOObjectFile or an Archive.
Differential revision: https://reviews.llvm.org/D67700
Test plan: make check-all
llvm-svn: 372278
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
update_{llc,mir}_test_checks.py applicability is determined by the
output (assembly or MIR), not the input, which makes
update_llc_test_checks.py the right tool to generate tests that start at
MIR and stop at the final assembly.
This commit adds the minimal support for this path. Main limitation that
remains:
- MIR has to have LLVM IR section, and the CHECK lines will be inserted
into the LLVM IR functions that correspond to the MIR functions.
Running
../utils/update_llc_test_checks.py --llc-binary ./bin/llc
on a slightly modified ../test/CodeGen/X86/bad-tls-fold.mir
produces the following diff:
+# NOTE: Assertions have been autogenerated by utils/update_llc_test_checks.py
+# RUN: llc %s -o - | FileCheck %s
--- |
target triple = "x86_64-unknown-linux-gnu"
@@ -6,17 +7,31 @@
@i = external thread_local global i32
define i32 @or() {
+ ; CHECK-LABEL: or:
+ ; CHECK: # %bb.0: # %entry
+ ; CHECK-NEXT: movq {{.*}}(%rip), %rax
+ ; CHECK-NEXT: orq $7, %rax
+ ; CHECK-NEXT: movq i@{{.*}}(%rip), %rcx
+ ; CHECK-NEXT: orq %rax, %rcx
+ ; CHECK-NEXT: movl %fs:(%rcx), %eax
+ ; CHECK-NEXT: retq
entry:
ret i32 undef
}
-
define i32 @and() {
+ ; CHECK-LABEL: and:
+ ; CHECK: # %bb.0: # %entry
+ ; CHECK-NEXT: movq {{.*}}(%rip), %rax
+ ; CHECK-NEXT: orq $7, %rax
+ ; CHECK-NEXT: movq i@{{.*}}(%rip), %rcx
+ ; CHECK-NEXT: andq %rax, %rcx
+ ; CHECK-NEXT: movl %fs:(%rcx), %eax
+ ; CHECK-NEXT: retq
entry:
ret i32 undef
}
...
(not applied)
llvm-svn: 372277
|
|
|
|
|
|
|
|
| |
Very minor change aiming to make it easier to extend the script
downstream to support non-llc, but llc-like tools. The main objective is
to decrease the probability of merge conflicts.
llvm-svn: 372276
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Large slowdowns were observed in Rust due to many small, constant
sized copies in conjunction with poorly-optimized memory.copy
implementations. Since memory.copy cannot be expected to be inlined
efficiently by engines at this time, stop using it for the smallest
copies. We continue to lower all memcpy intrinsics to memory.copy,
though.
Reviewers: aheejin, alexcrichton
Subscribers: dschuff, sbc100, jgravelle-google, hiraditya, JDevlieghere, sunfish, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D67639
llvm-svn: 372275
|
|
|
|
|
|
| |
This commit moves several topics to new categories. It also removes a few duplicate links in Subsystem Documentation.
llvm-svn: 372274
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Since we now lower most tail calls, it makes sense to support musttail.
Instead of always falling back to SelectionDAG, only fall back when a musttail
call was not able to be emitted as a tail call. Once we can handle most
incoming and outgoing arguments, we can change this to a `report_fatal_error`
like in ISelLowering.
Remove the assert that we don't have varargs and a musttail, and replace it
with a return false. Implementing this requires that we implement
`saveVarArgRegisters` from AArch64ISelLowering, which is an entirely different
patch.
Add GlobalISel lines to vararg-tallcall.ll to make sure that we produce correct
code. Right now we only fall back, but eventually this will be relevant.
Differential Revision: https://reviews.llvm.org/D67681
llvm-svn: 372273
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
DIFlagBlockByRefStruct is an unused DIFlag that originally was used by
clang to express (Objective-)C block captures in debug info. For the
last year Clang has been emitting complex DIExpressions to describe
block captures instead, which makes all the code supporting this flag
redundant.
This patch removes the flag and all supporting "dead" code, so we can
reuse the bit for something else in the future.
Since this only affects debug info generated by Clang with the block
extension this mostly affects Apple platforms and I don't have any
bitcode compatibility concerns for removing this. The Verifier will
reject debug info that uses the bit and thus degrade gracefully when
LTO'ing older bitcode with a newer compiler.
rdar://problem/44304813
Differential Revision: https://reviews.llvm.org/D67453
llvm-svn: 372272
|
|
|
|
|
|
|
| |
Addressing post-commit code review feedback from Dávid Bolvanský -
thanks!
llvm-svn: 372271
|
|
|
|
| |
llvm-svn: 372270
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
diagnostic location construction
Summary:
https://bugs.llvm.org/show_bug.cgi?id=43102
In today's edition of "Is this any better now that it isn't crashing?", I'd like to show you a very interesting test case with loop widening.
Looking at the included test case, it's immediately obvious that this is not only a false positive, but also a very bad bug report in general. We can see how the analyzer mistakenly invalidated `b`, instead of its pointee, resulting in it reporting a null pointer dereference error. Not only that, the point at which this change of value is noted at is at the loop, rather then at the method call.
It turns out that `FindLastStoreVisitor` works correctly, rather the supplied explodedgraph is faulty, because `BlockEdge` really is the `ProgramPoint` where this happens.
{F9855739}
So it's fair to say that this needs improving on multiple fronts. In any case, at least the crash is gone.
Full ExplodedGraph: {F9855743}
Reviewers: NoQ, xazax.hun, baloghadamsoftware, Charusso, dcoughlin, rnkovacs, TWeaver
Subscribers: JesperAntonsson, uabelho, Ka-Ka, bjope, whisperity, szepet, a.sidorin, mikhail.ramalho, donat.nagy, dkrupp, gamesh411, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D66716
llvm-svn: 372269
|
|
|
|
| |
llvm-svn: 372268
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
existing datalayouts.
Summary:
Add function to AutoUpgrade to change the datalayout of old X86 datalayout strings.
This adds "-p270:32:32-p271:32:32-p272:64:64" to X86 datalayouts that are otherwise valid
and don't already contain it.
This also removes the compatibility changes in https://reviews.llvm.org/D66843.
Datalayout change in https://reviews.llvm.org/D64931.
Reviewers: rnk, echristo
Subscribers: hiraditya, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D67631
llvm-svn: 372267
|
|
|
|
|
|
|
|
| |
This was fixed in the ELF backend in https://reviews.llvm.org/D34554.
Differential Revision: https://reviews.llvm.org/D67676
llvm-svn: 372266
|
|
|
|
| |
llvm-svn: 372265
|
|
|
|
|
|
|
|
| |
Patch by Diego Treviño!
Differential Revision: https://reviews.llvm.org/D66320
llvm-svn: 372264
|
|
|
|
|
|
| |
Introduced in 1e9c1d2b7bfc.
llvm-svn: 372263
|
|
|
|
|
|
|
|
| |
MSAN bot complains that there is use-of-uninitialized-value
of this FreeStores later in IsWorthwhile().
Perhaps FreeStores needs to be stored in a vector?
llvm-svn: 372262
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
In https://svnweb.freebsd.org/changeset/base/349351, FreeBSD 13 and
higher transitioned to Secure-PLT for PowerPC. This part contains the
changes in clang's PPC architecture defaults.
Reviewers: emaste, jhibbits, hfinkel
Reviewed By: jhibbits
Subscribers: wuzish, nemanjai, krytarowski, kbarton, MaskRay, jsji, shchenz, steven.zhang, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D67119
llvm-svn: 372261
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
In https://svnweb.freebsd.org/changeset/base/349351, FreeBSD 13 and
higher transitioned to Secure-PLT for PowerPC. This part contains the
changes in llvm's PPC subtarget.
Reviewers: emaste, jhibbits, hfinkel
Reviewed By: jhibbits
Subscribers: wuzish, nemanjai, krytarowski, kbarton, MaskRay, jsji, shchenz, steven.zhang, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D67118
llvm-svn: 372260
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
`DAGCombiner::visitADDLikeCommutative()` already has a sibling fold:
`(add X, Carry) -> (addcarry X, 0, Carry)`
This fold, as suggested by @efriedma, helps recover from //some//
of the regressions of D62266
Reviewers: efriedma, deadalnix
Subscribers: javed.absar, kristof.beyls, llvm-commits, efriedma
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D62392
llvm-svn: 372259
|
|
|
|
|
|
| |
Carry) fold (D62392)
llvm-svn: 372258
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
I don't have a direct motivational case for this,
but it would be good to have this for completeness/symmetry.
This pattern is basically the motivational pattern from
https://bugs.llvm.org/show_bug.cgi?id=43251
but with different predicate that requires that the offset is non-zero.
The completeness bit comes from the fact that a similar pattern (offset != zero)
will be needed for https://bugs.llvm.org/show_bug.cgi?id=43259,
so it'd seem to be good to not overlook very similar patterns..
Proofs: https://rise4fun.com/Alive/21b
Also, there is something odd with `isKnownNonZero()`, if the non-zero
knowledge was specified as an assumption, it didn't pick it up (PR43267)
With this, i see no other missing folds for
https://bugs.llvm.org/show_bug.cgi?id=43251
Reviewers: spatel, nikic, xbolva00
Reviewed By: spatel
Subscribers: hiraditya, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D67412
llvm-svn: 372257
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
AArch64 GlobalISel doesn't support MachO's large code model, so this patch
adds a check for that combination before implicitly enabling it.
Reviewers: paquette
Subscribers: kristof.beyls, ributzka, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D67724
llvm-svn: 372256
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
instruction count
Summary:
As it can be see in the changed test, while `div` is really costly,
we were speculating it. This does not seem correct.
Also, the old code would run for every single insturuction in BB,
instead of eagerly bailing out as soon as there are too many instructions.
This function still has a problem that `PHINodeFoldingThreshold` is
per-basic-block, while it should be for all the basic blocks.
Reviewers: efriedma, craig.topper, dmgreen, jmolloy
Reviewed By: jmolloy
Subscribers: xbolva00, hiraditya, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D67315
llvm-svn: 372255
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
inline immediate
Summary:
As discussed in https://reviews.llvm.org/D62341#1515637,
for MIPS `add %x, -1` isn't optimal. Unlike X86 there
are no fastpaths to matearialize such `-1`/`1` vector constants,
and `sub %x, 1` results in better codegen,
so undo canonicalization
Reviewers: atanasyan, Petar.Avramovic, RKSimon
Reviewed By: atanasyan
Subscribers: sdardis, arichardson, hiraditya, jrtc27, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D66805
llvm-svn: 372254
|
|
|
|
|
|
| |
`add %x, C` as `sub %x, -C` if it results in inline immediate"
llvm-svn: 372253
|
|
|
|
|
|
|
|
| |
If the variable, used in the loop boundaries, is not captured in the
construct, this variable must be considered as undefined if it was
privatized.
llvm-svn: 372252
|