[lldb] Require x86 for various NativePDB, Breakpad and Minidump tests

These tests fail if you build without the x86 llvm backend.
Either because they use an x86 triple or try to backtrace which
requ

[lldb] Require x86 for various NativePDB, Breakpad and Minidump tests

These tests fail if you build without the x86 llvm backend.
Either because they use an x86 triple or try to backtrace which
requires some x86 knowledge to see all frames.

Reviewed By: labath

Differential Revision: https://reviews.llvm.org/D100194

show more ...

[FastISel] Flush local value map on every instruction

Local values are constants or addresses that can't be folded into
the instruction that uses them. FastISel materializes these in a
"local value"

[FastISel] Flush local value map on every instruction

Local values are constants or addresses that can't be folded into
the instruction that uses them. FastISel materializes these in a
"local value" area that always dominates the current insertion
point, to try to avoid materializing these values more than once
(per block).

https://reviews.llvm.org/D43093 added code to sink these local
value instructions to their first use, which has two beneficial
effects. One, it is likely to avoid some unnecessary spills and
reloads; two, it allows us to attach the debug location of the
user to the local value instruction. The latter effect can
improve the debugging experience for debuggers with a "set next
statement" feature, such as the Visual Studio debugger and PS4
debugger, because instructions to set up constants for a given
statement will be associated with the appropriate source line.

There are also some constants (primarily addresses) that could be
produced by no-op casts or GEP instructions; the main difference
from "local value" instructions is that these are values from
separate IR instructions, and therefore could have multiple users
across multiple basic blocks. D43093 avoided sinking these, even
though they were emitted to the same "local value" area as the
other instructions. The patch comment for D43093 states:

Local values may also be used by no-op casts, which adds the
register to the RegFixups table. Without reversing the RegFixups
map direction, we don't have enough information to sink these
instructions.

This patch undoes most of D43093, and instead flushes the local
value map after(*) every IR instruction, using that instruction's
debug location. This avoids sometimes incorrect locations used
previously, and emits instructions in a more natural order.

In addition, constants materialized due to PHI instructions are
not assigned a debug location immediately; instead, when the
local value map is flushed, if the first local value instruction
has no debug location, it is given the same location as the
first non-local-value-map instruction. This prevents PHIs
from introducing unattributed instructions, which would either
be implicitly attributed to the location for the preceding IR
instruction, or given line 0 if they are at the beginning of
a machine basic block. Neither of those consequences is good
for debugging.

This does mean materialized values are not re-used across IR
instruction boundaries; however, only about 5% of those values
were reused in an experimental self-build of clang.

(*) Actually, just prior to the next instruction. It seems like
it would be cleaner the other way, but I was having trouble
getting that to work.

This reapplies commits cf1c774d and dc35368c, and adds the
modification to PHI handling, which should avoid problems
with debugging under gdb.

Differential Revision: https://reviews.llvm.org/D91734

show more ...

Revert "[FastISel] Flush local value map on ever instruction" and dependent patches

This reverts commit cf1c774d6ace59c5adc9ab71b31e762c1be695b1.

This change caused several regressions in the gdb t

Revert "[FastISel] Flush local value map on ever instruction" and dependent patches

This reverts commit cf1c774d6ace59c5adc9ab71b31e762c1be695b1.

This change caused several regressions in the gdb test suite - at least
a sample of which was due to line zero instructions making breakpoints
un-lined. I think they're worth investigating/understanding more (&
possibly addressing) before moving forward with this change.

Revert "[FastISel] NFC: Clean up unnecessary bookkeeping"
This reverts commit 3fd39d3694d32efa44242c099e923a7f4d982095.

Revert "[FastISel] NFC: Remove obsolete -fast-isel-sink-local-values option"
This reverts commit a474657e30edccd9e175d92bddeefcfa544751b2.

Revert "Remove static function unused after cf1c774."
This reverts commit dc35368ccf17a7dca0874ace7490cc3836fb063f.

Revert "[lldb] Fix TestThreadStepOut.py after "Flush local value map on every instruction""
This reverts commit 53a14a47ee89dadb8798ca8ed19848f33f4551d5.

show more ...

[FastISel] Flush local value map on ever instruction

Local values are constants or addresses that can't be folded into
the instruction that uses them. FastISel materializes these in a
"local value"

[FastISel] Flush local value map on ever instruction

Local values are constants or addresses that can't be folded into
the instruction that uses them. FastISel materializes these in a
"local value" area that always dominates the current insertion
point, to try to avoid materializing these values more than once
(per block).

https://reviews.llvm.org/D43093 added code to sink these local
value instructions to their first use, which has two beneficial
effects. One, it is likely to avoid some unnecessary spills and
reloads; two, it allows us to attach the debug location of the
user to the local value instruction. The latter effect can
improve the debugging experience for debuggers with a "set next
statement" feature, such as the Visual Studio debugger and PS4
debugger, because instructions to set up constants for a given
statement will be associated with the appropriate source line.

There are also some constants (primarily addresses) that could be
produced by no-op casts or GEP instructions; the main difference
from "local value" instructions is that these are values from
separate IR instructions, and therefore could have multiple users
across multiple basic blocks. D43093 avoided sinking these, even
though they were emitted to the same "local value" area as the
other instructions. The patch comment for D43093 states:

Local values may also be used by no-op casts, which adds the
register to the RegFixups table. Without reversing the RegFixups
map direction, we don't have enough information to sink these
instructions.

This patch undoes most of D43093, and instead flushes the local
value map after(*) every IR instruction, using that instruction's
debug location. This avoids sometimes incorrect locations used
previously, and emits instructions in a more natural order.

This does mean materialized values are not re-used across IR
instruction boundaries; however, only about 5% of those values
were reused in an experimental self-build of clang.

(*) Actually, just prior to the next instruction. It seems like
it would be cleaner the other way, but I was having trouble
getting that to work.

Differential Revision: https://reviews.llvm.org/D91734

show more ...

Reapply "RegAllocFast: Rewrite and improve"

This reverts commit 73a6a164b84a8195defbb8f5eeb6faecfc478ad4.

Revert "Reapply Revert "RegAllocFast: Rewrite and improve""

This reverts commit 55f9f87da2c2ad791b9e62cccb1c035e037444fa.

Breaks following buildbots:
http://lab.llvm.org:8011/builders/lldb-arm-ubun

Revert "Reapply Revert "RegAllocFast: Rewrite and improve""

This reverts commit 55f9f87da2c2ad791b9e62cccb1c035e037444fa.

Breaks following buildbots:
http://lab.llvm.org:8011/builders/lldb-arm-ubuntu/builds/4306
http://lab.llvm.org:8011/builders/lldb-aarch64-ubuntu/builds/9154

show more ...

Reapply Revert "RegAllocFast: Rewrite and improve"

This reverts commit dbd53a1f0c939a55e7719c39d08179468f9ad3dc.

Needed lldb test updates

Reapply [LLDB] [test] Use %clang_cl instead of build.py in a few tests

This allows explicitly specifying the intended target architecture,
for tests that aren't supposed to be executed, and that don

Reapply [LLDB] [test] Use %clang_cl instead of build.py in a few tests

This allows explicitly specifying the intended target architecture,
for tests that aren't supposed to be executed, and that don't
require MSVC headers or libraries to be available.

(These tests already implicitly assumed to be built for x86; one
didn't specify anything, assuming x86_64, while the other specified
--arch=32, which only picks the 32 bit variant of the default target
architecture).

Join two comment lines in disassembly.cpp, to keep row numbers
checked in the test unchanged.

This fixes running check-lldb on arm linux.

Previously when this was applied (in 95980409e6), it broke
macos buildbots, as they added "-isysroot <path>" to all %clang*
substitutions, and clang-cl didn't support that.

Reapplying it without further changes to this patch, after D69619
(9c73925226), because now, such extra parameters are added to
%clang_host*, but not to plain %clang_cl.

Differential Revision: https://reviews.llvm.org/D69031

show more ...

Revert "[LLDB] [test] Use %clang_cl instead of build.py in a few tests"

This reverts SVN r375156, as it seems to have broken tests when run
on macOS: http://green.lab.llvm.org/green/view/LLDB/job/ll

Revert "[LLDB] [test] Use %clang_cl instead of build.py in a few tests"

This reverts SVN r375156, as it seems to have broken tests when run
on macOS: http://green.lab.llvm.org/green/view/LLDB/job/lldb-cmake/2706/console

llvm-svn: 375163

show more ...

[LLDB] [test] Use %clang_cl instead of build.py in a few tests

This allows explicitly specifying the intended target architecture,
for tests that aren't supposed to be executed, and that don't
requi

[LLDB] [test] Use %clang_cl instead of build.py in a few tests

This allows explicitly specifying the intended target architecture,
for tests that aren't supposed to be executed, and that don't
require MSVC headers or libraries to be available.

(These tests already implicitly assumed to be built for x86; one
didn't specify anything, assuming x86_64, while the other specified
--arch=32, which only picks the 32 bit variant of the default target
architecture).

Join two comment lines in disassembly.cpp, to keep row numbers
checked in the test unchanged.

This fixes running check-lldb on arm linux.

Differential Revision: https://reviews.llvm.org/D69031

llvm-svn: 375156

show more ...

Re-land "[test] Split LLDB tests into API, Shell & Unit"

The original patch got reverted because it broke `check-lldb` on a clean
build. This fixes that.

llvm-svn: 374201

[test] Split LLDB tests into API, Shell & Unit

LLDB has three major testing strategies: unit tests, tests that exercise
the SB API though dotest.py and what we currently call lit tests. The
later is

[test] Split LLDB tests into API, Shell & Unit

LLDB has three major testing strategies: unit tests, tests that exercise
the SB API though dotest.py and what we currently call lit tests. The
later is rather confusing as we're now using lit as the driver for all
three types of tests. As most of this grew organically, the directory
structure in the LLDB repository doesn't really make this clear.

The 'lit' tests are part of the root and among these tests there's a
Unit and Suite folder for the unit and dotest-tests. This layout makes
it impossible to run just the lit tests.

This patch changes the directory layout to match the 3 testing
strategies, each with their own directory and their own configuration
file. This means there are now 3 directories under lit with 3
corresponding targets:

- API (check-lldb-api): Test exercising the SB API.
- Shell (check-lldb-shell): Test exercising command line utilities.
- Unit (check-lldb-unit): Unit tests.

Finally, there's still the `check-lldb` target that runs all three test
suites.

Finally, this also renames the lit folder to `test` to match the LLVM
repository layout.

Differential revision: https://reviews.llvm.org/D68606

llvm-svn: 374184

show more ...