| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
I'm not sure why this surfaced at this particular point, but
TestCommandScriptImmediateOutput (a pexpect test) had a synchronization
issue, where the (lldb) promts it was expecting were getting out of
sync. This happened for two reasons:
- it did not expect the initial (lldb) prompt we print at startup
- launchArgs() returned None, which resulted in an extra "target create
None" command being issued to lldb (and an extra unhandled prompt
being printed).
Resolving these two issues seems to fix (or at least, improve) the test.
llvm-svn: 357459
|
| |
|
|
|
|
| |
This makes it faster and saves 104 bytes for my build.
llvm-svn: 357458
|
| |
|
|
|
|
|
|
| |
-internalize-public-api-file
This makes my libLLVMipo.so.9svn smaller by 360 bytes.
llvm-svn: 357457
|
| |
|
|
|
|
|
|
|
|
| |
The test was hitting llvm_unreachable in
Platform::GetSoftwareBreakpointTrapOpcode because it could not figure
out the architecture of the process. Since that is not the purpose of
the test, I change the test to use an explicit
CreateTargetWithFileAndTargetTriple command to specify it.
llvm-svn: 357456
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This refactors moves the register name->number resolution out of the
FPOProgramNodeRegisterRef class. Instead I create a special
FPOProgramNodeSymbol class, which holds unresolved symbols, and move the
resolution into the ResolveRegisterRefs visitor.
The background here is that I'd like to use this code for Breakpad
unwind info, which uses similar syntax to describe unwind info. For
example, a simple breakpad unwind program might look like:
.cfa: $esp 8 + $ebp: .cfa 8 - ^
To be able to do this, I need to be able to customize register
resolving, as that is presently hardcoded to use codeview register
names, but breakpad supports a lot more architectures with different
register names. Moving the resolution into a separate class will allow
each user to use a different resolution logic.
Reviewers: aleksandr.urakov, zturner, amccarth
Subscribers: jdoerfert, lldb-commits
Differential Revision: https://reviews.llvm.org/D60068
llvm-svn: 357455
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Patch by Nathan Ridge.
Reviewers: gribozavr
Reviewed By: gribozavr
Subscribers: ilya-biryukov, ioeric, MaskRay, jkorous, arphaman, kadircet, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D60040
llvm-svn: 357454
|
| |
|
|
|
|
|
|
| |
The current definitions were entirely broken. They didn't call any
existing constructor and the forgot to friend the expression types they
were trying to construct.
llvm-svn: 357453
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
used results (PR41259)
The code was previously checking that candidates for sinking had exactly
one use or were a store instruction (which can't have uses). This meant
we could sink call instructions only if they had a use.
That limitation seemed a bit arbitrary, so this patch changes it to
"instruction has zero or one use" which seems more natural and removes
the need to special-case stores.
Differential revision: https://reviews.llvm.org/D59936
llvm-svn: 357452
|
| |
|
|
|
|
|
|
| |
While reviewing D56233 it became clear to me that this test can be
simplified. There's no need for a start-stop cycle in the inferior -- we
can start fiddling with its registers as soon as it is launched.
llvm-svn: 357451
|
| |
|
|
|
|
|
|
|
|
| |
llvm-ar is a crunchgen-style executable dispatching to dlltool,ranlib,lib,ar based on argv[0].
In our content-addressable storage, readlink -f resolves paths to some
digest and thus lost the original "llvm-ar" filename.
Replace it with a custom path resolution to fix the problem.
llvm-svn: 357450
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Patch from 'troyj':
Hi, I ran into a problem with this test when the source was located in
certain directories. The mkdir(2) man page states that the set-group-ID
bit is inherited from the parent directory, but this test was written in
such a way that it assumes the bit is unset. Whether that assumption is
true depends on where the checkout lives, which leads to some people
being able to reproduce the problem whereas others cannot. I think the
correct fix is to exclude the bit from the check.
Making probinson a reviewer since they reviewed the original test.
Patch landed for troyj, thanks!
Differential Revision: D53832
llvm-svn: 357449
|
| |
|
|
|
|
| |
The code doesn't actually need any of the information about the widenable condition at this level. The only thing we need is to ensure the WC call is the last thing anded in, and even that is a quirk we should really look to remove.
llvm-svn: 357448
|
| |
|
|
|
|
|
|
|
|
| |
isPotentiallyReachable.
The leads to some ambiguous overloads, so update three callers.
Differential Revision: https://reviews.llvm.org/D60085
llvm-svn: 357447
|
| |
|
|
|
|
|
|
| |
Add +/-slow-incdec command lines
We only form inc/dec in FixupLEAs under minsize today, but all other locations in the compiler for inc/dec with optsize.
llvm-svn: 357446
|
| |
|
|
| |
llvm-svn: 357445
|
| |
|
|
|
|
| |
All of the interfaces related to opcode in MachineInstr and MCInstrInfo refer to opcodes as unsigned.
llvm-svn: 357444
|
| |
|
|
| |
llvm-svn: 357443
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: - Add more test cases.
Reviewers: arsenm
Subscribers: kzhuravl, jvesely, wdng, nhaehnle, yaxunl, dstuttard, tpr, t-tye, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D60071
llvm-svn: 357442
|
| |
|
|
| |
llvm-svn: 357441
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
There's an existing optimization for x != C, but somehow it was missing
a special case for 0.
While I'm here, also cleaned up the code/comments a bit: the second
value produced by the MERGE_VALUES was actually dead, since a CMOV only
produces one result.
Differential Revision: https://reviews.llvm.org/D59616
llvm-svn: 357437
|
| |
|
|
|
|
|
|
|
|
|
|
| |
It's a little tricky to make this issue show up because
prologue/epilogue emission normally likes to push at least two
registers... but it doesn't when lr is force-spilled due to function
length. Not sure if that really makes sense, but I decided not to touch
it for now.
Differential Revision: https://reviews.llvm.org/D59385
llvm-svn: 357436
|
| |
|
|
| |
llvm-svn: 357433
|
| |
|
|
|
|
|
|
|
| |
This improves selection for vector stores into v2s64s. Before we just
scalarized them, but we can just use a STRQui instead.
Differential Revision: https://reviews.llvm.org/D60083
llvm-svn: 357432
|
| |
|
|
|
|
| |
This patch removes spurious links against Python.
llvm-svn: 357431
|
| |
|
|
|
|
| |
WIN32 is not defined, _WIN32 is, use that instead.
llvm-svn: 357429
|
| |
|
|
|
|
|
|
|
|
| |
I found the code of Process::WriteMemory particularly hard to follow
when reviewing Ismail's change in D60022. This simplifies the code and
hopefully prevents similar oversights in the future.
Differential revision: https://reviews.llvm.org/D60092
llvm-svn: 357428
|
| |
|
|
|
|
|
|
| |
whitespace.
Differential Revision: https://reviews.llvm.org/D60084
llvm-svn: 357427
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This change prevents the lldb-vscode test harness from hanging up waiting for
new messages when the lldb-vscode subprocess crashes.
Now, when an EOF from the subprocess pipe is detected we enqueue a `None` packet
in the received packets list. Then, during the message processing loop, we can
use this `None` packet to tell apart the case where lldb-vscode has terminated
unexpectedly from the normal situation where no pending messages means blocking
and waiting for more data.
I believe this should be enough to fix the issues with these tests hanging on
multiple platforms. Once this lands, I'll prepare and test a separate change
removing the @skipIfLinux annotations.
Reviewers: clayborg, zturner
Subscribers: lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D59849
llvm-svn: 357426
|
| |
|
|
|
|
| |
Fixes a bug in isPotentiallyReachable, noticed by inspection.
llvm-svn: 357425
|
| |
|
|
| |
llvm-svn: 357424
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Summary: Completes P0357R3, which was merged into the C++20 Working Draft in San Diego.
Reviewers: EricWF, mclow.lists
Subscribers: christof, jkorous, dexonsmith, libcxx-commits
Differential Revision: https://reviews.llvm.org/D54722
llvm-svn: 357423
|
| |
|
|
| |
llvm-svn: 357422
|
| |
|
|
|
|
| |
r357383
llvm-svn: 357421
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
In case of a breakpoint site overlapping with the destination address,
the WriteMemory method reported an incorrect memory size.
Instead of returning the right amount of bytes written, it falls through
the scope and returned 0.
Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
Reviewers: jasonmolenda, friss, jingham
Subscribers: JDevlieghere, davide, lldb-commits, #lldb
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D60022
llvm-svn: 357420
|
| |
|
|
|
|
|
|
|
|
| |
X86::OPERAND_ROUNDING_CONTROL instead of MCOI::OPERAND_IMMEDIATE. Add an assert on legal values of rounding control in the encoder and remove an explicit mask.
This should allow llvm-exegesis to intelligently constrain the rounding mode.
The mask in the encoder shouldn't be necessary any more. We used to allow codegen to use 8-11 for rounding mode and the assembler would use 0-3 to mean the same thing so we masked here and in the printer. Codegen now matches the assembler and the printer was updated, but I forgot to update the encoder.
llvm-svn: 357419
|
| |
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D60054
llvm-svn: 357418
|
| |
|
|
|
|
|
|
|
|
|
|
| |
combineEhFrameSections(). NFCI.
And rename the function to combineEhSections(). This makes the processing
of .ARM.exidx even more similar to .eh_frame and means that we can avoid an
additional loop over InputSections.
Differential Revision: https://reviews.llvm.org/D60026
llvm-svn: 357417
|
| |
|
|
|
|
| |
methods. NFCI.
llvm-svn: 357416
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
transformation.
Before this patch, CGLoop would dump all transformations for a loop into
a single LoopID without encoding any order in which to apply them.
rL348944 added the possibility to encode a transformation order using
followup-attributes.
When a loop has more than one transformation, use the follow-up
attribute define the order in which they are applied. The emitted order
is the defacto order as defined by the current LLVM pass pipeline,
which is:
LoopFullUnrollPass
LoopDistributePass
LoopVectorizePass
LoopUnrollAndJamPass
LoopUnrollPass
MachinePipeliner
This patch should therefore not change the assembly output, assuming
that all explicit transformations can be applied, and no implicit
transformations in-between. In the former case,
WarnMissedTransformationsPass should emit a warning (except for
MachinePipeliner which is not implemented yet). The latter could be
avoided by adding 'llvm.loop.disable_nonforced' attributes.
Because LoopUnrollAndJamPass processes a loop nest, generation of the
MDNode is delayed to after the inner loop metadata have been processed.
A temporary LoopID is therefore used to annotate instructions and
RAUW'ed by the actual LoopID later.
Differential Revision: https://reviews.llvm.org/D57978
llvm-svn: 357415
|
| |
|
|
| |
llvm-svn: 357414
|
| |
|
|
|
|
| |
thanks to Ivan Afanasyev for the report.
llvm-svn: 357413
|
| |
|
|
|
|
|
|
|
|
| |
According to OpenMP 5.0, 2.11.4 allocate Clause, Restrictions, allocate
clauses that appear on a target construct or on constructs in a target
region must specify an allocator expression unless a requires directive
with the dynamic_allocators clause is present in the same compilation
unit. Patch adds a check for this restriction.
llvm-svn: 357412
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Similarly to https://reviews.llvm.org/rL350972, this revision changes
std::tuple_element from class to struct.
Fixes PR41331.
Thanks to Jan Wilken Dörrie for the patch.
Differential Revision: https://reviews.llvm.org/D60069
llvm-svn: 357411
|
| |
|
|
|
|
| |
to Zulan for the report, and Howard for the direction of the fix.
llvm-svn: 357410
|
| |
|
|
|
|
|
|
| |
This test case was approved as part of
https://reviews.llvm.org/D49434, but was accidentally
omitted from the final commit.
llvm-svn: 357409
|
| |
|
|
|
|
| |
We'd been optimizing the case where the predicate was obviously true, do the same for the false case. Mostly just for completeness sake, but also may improve compile time in loops which will exit through the guard. Such loops are presumed rare in fastpath code, but may be present down untaken paths, so optimizing for them is still useful.
llvm-svn: 357408
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Previously, we translate llvm.round to PTX cvt.rni, which rounds to the
even interger when the source is equidistant between two integers. This
is not correct as llvm.round should round away from zero. This change
replaces llvm.round with a round away from zero implementation through
target specific custom lowering.
Modify a few affected tests to not check for cvt.rni. Instead, we check
for the use of a few constants used in implementing round. We are also
adding CUDA runnable tests to check for the values produced by
llvm.round to test-suites/External/CUDA.
Reviewers: tra
Subscribers: jholewinski, sanjoy, jlebar, hiraditya, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D59947
llvm-svn: 357407
|
| |
|
|
|
|
| |
LoopPredication was replacing the original condition, but leaving the instructions to compute the old conditions around. This would get cleaned up by other passes of course, but we might as well do it eagerly. That also makes the test output less confusing.
llvm-svn: 357406
|
| |
|
|
| |
llvm-svn: 357405
|
| |
|
|
|
|
| |
I'm about to make some changes to the pass which cause widespread - but uninteresting - test diffs. Prepare the tests for easy updating.
llvm-svn: 357404
|