| Commit message (Collapse) | Author | Age | Files | Lines |
| | |
|
| |
|
|
|
| |
This reverts commit 7bc7fe6b789d25d48d6dc71d533a411e9e981237.
The immediate callers have been fixed to pass nullopt where appropriate.
|
| |
|
|
|
|
| |
This reverts commit 40668abca4d307e02b33345cfdb7271549ff48d0.
This causes clang tests to fail, as stacksize=0 is being explicitly passed and
is no longer a no-op.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This roughly mimics `std::thread(...).detach()` except it allows to
customize the stack size. Required for https://reviews.llvm.org/D50993.
I've decided against reusing the existing `llvm_execute_on_thread` because
it's not obvious what to do with the ownership of the passed
function/arguments:
1. If we pass possibly owning functions data to `llvm_execute_on_thread`,
we'll lose the ability to pass small non-owning non-allocating functions
for the joining case (as it's used now). Is it important enough?
2. If we use the non-owning interface in the new use case, we'll force
clients to transfer ownership to the spawned thread manually, but
similar code would still have to exist inside
`llvm_execute_on_thread(_async)` anyway (as we can't just pass the same
non-owning pointer to pthreads and Windows implementations, and would be
forced to wrap it in some structure, and deal with its ownership.
Patch by Dmitry Kozhevnikov!
Differential Revision: https://reviews.llvm.org/D51103
|
| |
|
|
|
|
|
|
|
|
| |
MipsMCAsmInfo was using '$' prefix for Mips32 and '.L' for Mips64
regardless of -target-abi option. By passing MCTargetOptions to MCAsmInfo
we can find out Mips ABI and pick appropriate prefix.
Tags: #llvm, #clang, #lldb
Differential Revision: https://reviews.llvm.org/D66795
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
The default implementation of the describeLoadedValue() hook uses the
MoveImm property to determine if an instruction moves an immediate. If
an instruction has that property the function returns the second
operand, assuming that that is the immediate value the instruction
moves. As far as I can tell, the MoveImm property does not imply that
the second operand is the immediate value, nor that any other operand
necessarily holds the immediate value; it just means that the
instruction moves some immediate value.
One example where the second operand is not the immediate is SystemZ's
LZER instruction, which moves a zero immediate implicitly: $f0S = LZER.
That case triggered an out-of-bound assertion when getting the operand.
I have added a test case for that instruction.
Another example is ARM's MVN instruction, which holds the logical
bitwise NOT'd value of the immediate that is moved. For the following
reproducer:
extern void foo(int);
int main() { foo(-11); }
an incorrect call site value would be emitted:
$ clang --target=arm foo.c -O1 -g -Xclang -femit-debug-entry-values \
-c -o - | ./build/bin/llvm-dwarfdump - | \
grep -A2 call_site_parameter
0x00000058: DW_TAG_GNU_call_site_parameter
DW_AT_location (DW_OP_reg0 R0)
DW_AT_GNU_call_site_value (DW_OP_lit10)
Another example is the A2_combineii instruction on Hexagon which moves
two immediates to a super-register: $d0 = A2_combineii 20, 10.
Perhaps these are rare exceptions, and most MoveImm instructions hold
the immediate in the second operand, but in my opinion the default
implementation of the hook should only describe values that it can, by
some contract, guarantee are safe to describe, rather than leaving it up
to the targets to override the exceptions, as that can silently result
in incorrect call site values.
This patch adds X86's relevant move immediate instructions to the
target's hook implementation, so this commit should be a NFC for that
target. We need to do the same for ARM and AArch64.
Reviewers: djtodoro, NikolaPrica, aprantl, vsk
Reviewed By: vsk
Subscribers: kristof.beyls, hiraditya, llvm-commits
Tags: #debug-info, #llvm
Differential Revision: https://reviews.llvm.org/D69109
|
| |
|
|
| |
A test commit.
|
| |
|
|
|
|
|
|
|
|
| |
Select vector G_MUL for MIPS32 with MSA. We have to set bank
for vector operands to fprb and selectImpl will do the rest.
Manual selection of G_MUL is now done for gprb only.
__builtin_msa_mulv_<format> will be transformed into G_MUL
in legalizeIntrinsic and selected in the same way.
Differential Revision: https://reviews.llvm.org/D69310
|
| |
|
|
|
|
|
|
|
|
|
| |
Select vector G_SUB for MIPS32 with MSA. We have to set bank
for vector operands to fprb and selectImpl will do the rest.
__builtin_msa_subv_<format> will be transformed into G_SUB
in legalizeIntrinsic and selected in the same way.
__builtin_msa_subvi_<format> will be directly selected into
SUBVI_<format> in legalizeIntrinsic.
Differential Revision: https://reviews.llvm.org/D69306
|
| |
|
|
|
|
|
|
|
|
|
|
| |
checks (PR43769)
We should do the fold only if both constants are plain,
non-opaque constants, at least that is the DAG.FoldConstantArithmetic()
requirement.
And if the constant we are comparing with is zero - we shouldn't be
trying to do this fold in the first place.
Fixes https://bugs.llvm.org/show_bug.cgi?id=43769
|
| |
|
|
|
|
|
|
|
|
|
| |
This adds support for reserving GPRs such that the compiler will not
choose a register for register allocation. The implementation follows
the same design as for AArch64; each reserved register becomes a target
feature and used for getting the reserved registers for a given
MachineFunction. The backend checks that it does not need to write to
any reserved register; if it does a relevant error is generated.
Differential Revision: https://reviews.llvm.org/D67185
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
into the x node.
Summary:
This fold, helps recover from the rest of the D62266 ARM regressions.
https://rise4fun.com/Alive/TvpC
Note that while the fold is quite flexible, i've restricted it
to the single interesting pattern at the moment.
Reviewers: efriedma, craig.topper, spatel, RKSimon, deadalnix
Reviewed By: deadalnix
Subscribers: javed.absar, kristof.beyls, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D62450
|
| | |
|
| |
|
|
|
|
| |
Turns out it makes sense, contrarily to what comment said.
Differential Revision: https://reviews.llvm.org/D69287
|
| |
|
|
|
|
|
|
|
|
|
|
| |
This adds an instcombine matcher for code that attempts to perform signed
saturating arithmetic by casting to a higher type. Unsigned cases are already
matched, this adds extra matches for the more complex signed cases, which
involves matching the min(max(add a b)) nodes with proper extends to ensure
legality.
Differential Revision: https://reviews.llvm.org/D68651
llvm-svn: 375505
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
MachineRegisterInfo::createGenericVirtualRegister sets
RegClassOrRegBank to static_cast<RegisterBank *>(nullptr).
MIParser on the other hand doesn't. When we attempt to constrain
Register Class on such VReg, additional COPY is generated.
This way we avoid COPY instructions showing in test that have MIR
input while they are not present with llvm-ir input that was used
to create given MIR for a -run-pass test.
Differential Revision: https://reviews.llvm.org/D68946
llvm-svn: 375502
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Select vector G_ADD for MIPS32 with MSA. We have to set bank
for vector operands to fprb and selectImpl will do the rest.
__builtin_msa_addv_<format> will be transformed into G_ADD
in legalizeIntrinsic and selected in the same way.
__builtin_msa_addvi_<format> will be directly selected into
ADDVI_<format> in legalizeIntrinsic. MIR tests for it have
unnecessary additional copies. Capture current state of tests
with run-pass=legalizer with a test in test/CodeGen/MIR/Mips.
Differential Revision: https://reviews.llvm.org/D68984
llvm-svn: 375501
|
| |
|
|
| |
llvm-svn: 375500
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This is patch is part of a series to introduce an Alignment type.
See this thread for context: http://lists.llvm.org/pipermail/llvm-dev/2019-July/133851.html
See this patch for the introduction of the type: https://reviews.llvm.org/D64790
Reviewers: courbet
Subscribers: hiraditya, jfb, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D69303
llvm-svn: 375499
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This is patch is part of a series to introduce an Alignment type.
See this thread for context: http://lists.llvm.org/pipermail/llvm-dev/2019-July/133851.html
See this patch for the introduction of the type: https://reviews.llvm.org/D64790
Reviewers: courbet
Subscribers: hiraditya, jfb, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D69302
llvm-svn: 375498
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
This re-commits r375152 which was pulled in r375233 because it broke
the EXPENSIVE_CHECKS bot on Windows.
The reason for the failure was a bug in the pass that the commit turned
on by default. This patch fixes that bug and turns the pass back on.
This patch has been verified on the buildbot that originally failed
thanks to Simon Pilgrim.
Differential revision: https://reviews.llvm.org/D52431
llvm-svn: 375497
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This is patch is part of a series to introduce an Alignment type.
See this thread for context: http://lists.llvm.org/pipermail/llvm-dev/2019-July/133851.html
See this patch for the introduction of the type: https://reviews.llvm.org/D64790
Reviewers: courbet
Subscribers: hiraditya, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D69300
llvm-svn: 375496
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This is patch is part of a series to introduce an Alignment type.
See this thread for context: http://lists.llvm.org/pipermail/llvm-dev/2019-July/133851.html
See this patch for the introduction of the type: https://reviews.llvm.org/D64790
Reviewers: courbet
Subscribers: jholewinski, hiraditya, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D69278
llvm-svn: 375495
|
| |
|
|
|
|
| |
Differential revision: https://reviews.llvm.org/D69107
llvm-svn: 375493
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Currently injected-sources-native.test fails with "Expected<T>
value was in success state.
(Note: Expected<T> values in success mode must still be checked
prior to being destroyed)"
when llvm is compiled with LLVM_ENABLE_ABI_BREAKING_CHECKS in Release.
The problem is that getStringForID returns Expected<StringRef>
and Expected value must always be checked, even if it is in success state.
Checking with assert only helps in Debug and is wrong.
Differential revision: https://reviews.llvm.org/D69251
llvm-svn: 375492
|
| |
|
|
|
|
| |
Stop hardwiring classes
llvm-svn: 375470
|
| |
|
|
|
|
| |
reduction combine
llvm-svn: 375463
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Reviewers: arsenm
Reviewed By: arsenm
Subscribers: kzhuravl, jvesely, wdng, nhaehnle, yaxunl, rovka, dstuttard, tpr, t-tye, hiraditya, Petar.Avramovic, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D69231
llvm-svn: 375460
|
| |
|
|
| |
llvm-svn: 375457
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This is the last `OverflowingBinaryOperator` for which we don't deduce flags.
D69217 taught `ConstantRange::makeGuaranteedNoWrapRegion()` about it.
The effect is better than of the `mul` patch (D69203):
| statistic | old | new | delta | % change |
| correlated-value-propagation.NumAddNUW | 7145 | 7144 | -1 | -0.0140% |
| correlated-value-propagation.NumAddNW | 12126 | 12125 | -1 | -0.0082% |
| correlated-value-propagation.NumAnd | 443 | 446 | 3 | 0.6772% |
| correlated-value-propagation.NumNSW | 5986 | 7158 | 1172 | 19.5790% |
| correlated-value-propagation.NumNUW | 10512 | 13304 | 2792 | 26.5601% |
| correlated-value-propagation.NumNW | 16498 | 20462 | 3964 | 24.0272% |
| correlated-value-propagation.NumShlNSW | 0 | 1172 | 1172 | |
| correlated-value-propagation.NumShlNUW | 0 | 2793 | 2793 | |
| correlated-value-propagation.NumShlNW | 0 | 3965 | 3965 | |
| instcount.NumAShrInst | 13824 | 13790 | -34 | -0.2459% |
| instcount.NumAddInst | 277584 | 277586 | 2 | 0.0007% |
| instcount.NumAndInst | 66061 | 66056 | -5 | -0.0076% |
| instcount.NumBrInst | 709153 | 709147 | -6 | -0.0008% |
| instcount.NumICmpInst | 483709 | 483708 | -1 | -0.0002% |
| instcount.NumSExtInst | 79497 | 79496 | -1 | -0.0013% |
| instcount.NumShlInst | 40691 | 40654 | -37 | -0.0909% |
| instcount.NumSubInst | 61997 | 61996 | -1 | -0.0016% |
| instcount.NumZExtInst | 68208 | 68211 | 3 | 0.0044% |
| instcount.TotalBlocks | 843916 | 843910 | -6 | -0.0007% |
| instcount.TotalInsts | 7387528 | 7387448 | -80 | -0.0011% |
Reviewers: nikic, reames, sanjoy, timshen
Reviewed By: nikic
Subscribers: hiraditya, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D69277
llvm-svn: 375455
|
| |
|
|
|
|
|
|
|
|
| |
Teach the CombinerHelper how to turn shuffle_vectors, that
concatenate vectors, into concat_vectors and add this combine
to the AArch64 pre-legalizer combiner.
Differential Revision: https://reviews.llvm.org/D69149
llvm-svn: 375452
|
| |
|
|
|
|
|
| |
This doesn't use the default value, so doesn't benefit from the hack
to help optimize it.
llvm-svn: 375450
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Only handle simple inter-block redefs of m0 to the same value. This
avoids interference from redefs of m0 in SILoadStoreOptimzer. I was
initially teaching that pass to ignore redefs of m0, but having them
not exist beforehand is much simpler.
This is in preparation for deleting the current special m0 handling in
SIFixSGPRCopies to allow the register coalescer to handle the
difficult cases.
llvm-svn: 375449
|
| |
|
|
|
|
|
|
| |
r375293 removed the SGPR spilling with scalar stores path, so this is
no longer necessary. This also always had the defect of adding the def
even when this path wasn't in use.
llvm-svn: 375448
|
| |
|
|
|
|
|
| |
This will allow using another operation to produce the glue in a
future change.
llvm-svn: 375447
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
If a PHI defines AGPR legalize its operands to AGPR.
At the moment we can get an AGPR PHI with VGPR operands.
I am not aware of any problems as it seems to be handled
gracefully in RA, but this is not right anyway.
It also slightly decreases VGPR pressure in some cases
because we do not have to a copy via VGPR.
Differential Revision: https://reviews.llvm.org/D69206
llvm-svn: 375446
|
| |
|
|
|
|
| |
This doesn't need to be just for bitops, but the ops do need to be fully associative.
llvm-svn: 375445
|
| |
|
|
| |
llvm-svn: 375444
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Reduce include dependencies by no longer including Pass.h from
DataLayout.h. That include seemed irrelevant to DataLayout, as
well as being irrelevant to several users of DataLayout.
Reviewers: rnk
Reviewed By: rnk
Subscribers: mehdi_amini, hiraditya, cfe-commits, llvm-commits
Tags: #clang, #llvm
Differential Revision: https://reviews.llvm.org/D69261
llvm-svn: 375436
|
| |
|
|
|
|
|
|
| |
dyn_cast<> null dereference warning. NFCI.
The static analyzer is warning about a potential null dereference, but we should be able to use cast<> directly and if not assert will fire for us.
llvm-svn: 375430
|
| |
|
|
|
|
|
|
| |
hasEHOrLoadsOnPath call. NFCI.
The static analyzer is warning about a potential null dereference, but we should be able to use cast<> directly and if not assert will fire for us.
llvm-svn: 375429
|
| |
|
|
|
|
| |
assertion. NFCI.
llvm-svn: 375428
|
| |
|
|
|
|
| |
The static analyzer is warning about a potential null dereference, but we should be able to use cast<> directly and if not assert will fire for us.
llvm-svn: 375427
|
| |
|
|
|
|
|
|
| |
warning. NFCI.
The static analyzer is warning about a potential null dereference, but we should be able to use cast<> directly and if not assert will fire for us.
llvm-svn: 375426
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Commit message from D66935:
This patch fixes a bug exposed by D65653 where a subsequent invocation
of `determineCalleeSaves` ends up with a different size for the callee
save area, leading to different frame-offsets in debug information.
In the invocation by PEI, `determineCalleeSaves` tries to determine
whether it needs to spill an extra callee-saved register to get an
emergency spill slot. To do this, it calls 'estimateStackSize' and
manually adds the size of the callee-saves to this. PEI then allocates
the spill objects for the callee saves and the remaining frame layout
is calculated accordingly.
A second invocation in LiveDebugValues causes estimateStackSize to return
the size of the stack frame including the callee-saves. Given that the
size of the callee-saves is added to this, these callee-saves are counted
twice, which leads `determineCalleeSaves` to believe the stack has
become big enough to require spilling an extra callee-save as emergency
spillslot. It then updates CalleeSavedStackSize with a larger value.
Since CalleeSavedStackSize is used in the calculation of the frame
offset in getFrameIndexReference, this leads to incorrect offsets for
variables/locals when this information is recalculated after PEI.
This patch fixes the lldb unit tests in `functionalities/thread/concurrent_events/*`
Changes after D66935:
Ensures AArch64FunctionInfo::getCalleeSavedStackSize does not return
the uninitialized CalleeSavedStackSize when running `llc` on a specific
pass where the MIR code has already been expected to have gone through PEI.
Instead, getCalleeSavedStackSize (when passed the MachineFrameInfo) will try
to recalculate the CalleeSavedStackSize from the CalleeSavedInfo. In debug
mode, the compiler will assert the recalculated size equals the cached
size as calculated through a call to determineCalleeSaves.
This fixes two tests:
test/DebugInfo/AArch64/asan-stack-vars.mir
test/DebugInfo/AArch64/compiler-gen-bbs-livedebugvalues.mir
that otherwise fail when compiled using msan.
Reviewed By: omjavaid, efriedma
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D68783
llvm-svn: 375425
|
| |
|
|
|
|
|
|
| |
Clean up PPCAsmPrinter with IsPPC64 and IsDarwin.
Differential Revision: https://reviews.llvm.org/D69259
llvm-svn: 375420
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This is patch is part of a series to introduce an Alignment type.
See this thread for context: http://lists.llvm.org/pipermail/llvm-dev/2019-July/133851.html
See this patch for the introduction of the type: https://reviews.llvm.org/D64790
Reviewers: courbet
Subscribers: hiraditya, asbirlea, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D69253
llvm-svn: 375419
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This is patch is part of a series to introduce an Alignment type.
See this thread for context: http://lists.llvm.org/pipermail/llvm-dev/2019-July/133851.html
See this patch for the introduction of the type: https://reviews.llvm.org/D64790
Subscribers: hiraditya, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D69256
llvm-svn: 375416
|
| |
|
|
|
|
|
|
|
| |
This adds some new qdadd patterns to go along with the other recently added
qadd's.
Differential Revision: https://reviews.llvm.org/D68999
llvm-svn: 375414
|
| |
|
|
|
|
|
|
|
|
|
|
| |
This lowers a sadd_sat to a qadd by treating it as legal. Also adds qsub at the
same time.
The qadd instruction sets the q flag, but we already have many cases where we
do not model this in llvm.
Differential Revision: https://reviews.llvm.org/D68976
llvm-svn: 375411
|