Haibo told me he didn't have any issues with Python 3.8 and I was able
to confirm that. Even though we don't have bot running with 3.8, I think
it safe to mark it as supported in the docs.
Summary: I don't see why we want to keep that code around.
Reviewers: #lldb, JDevlieghere
Reviewed By: #lldb, JDevlieghere
Subscribers: davide
Differential Revision: https://reviews.llvm.org/D75496
If we go with D75412, we no longer depend on the scalar type directly. So we don't need to avoid using i64. We already have AVX1 fallback patterns with i32 and i64 scalar types so we don't need to avoid using integer types on AVX1.
Differential Revision: https://reviews.llvm.org/D75413
Also add a DAG combine to combine different sized broadcasts from
constant pool to avoid a regression.
Differential Revision: https://reviews.llvm.org/D75412
Summary: This patch adds an analysis pass to collect loop nests and
summarize properties of the nest (e.g the nest depth, whether the nest
is perfect, what's the innermost loop, etc...).
The motivation for this patch was discussed at the latest meeting of the
LLVM loop group (https://ibm.box.com/v/llvm-loop-nest-analysis) where we
discussed
the unimodular loop transformation framework ( “A Loop Transformation
Theory and an Algorithm to Maximize Parallelism”, Michael E. Wolf and
Monica S. Lam, IEEE TPDS, October 1991). The unimodular framework
provides a convenient way to unify legality checking and code generation
for several loop nest transformations (e.g. loop reversal, loop
interchange, loop skewing) and their compositions. Given that the
unimodular framework is applicable to perfect loop nests this is one
property of interest we expose in this analysis. Several other utility
functions are also provided. In the future other properties of interest
can be added in a centralized place.
Authored By: etiotto
Reviewer: Meinersbur, bmahjour, kbarton, Whitney, dmgreen, fhahn,
reames, hfinkel, jdoerfert, ppc-slack
Reviewed By: Meinersbur
Subscribers: bryanpkc, ppc-slack, mgorny, hiraditya, llvm-commits
Tag: LLVM
Differential Revision: https://reviews.llvm.org/D68789
Summary:
Introduce support for converting loop.for operations with loop-carried values
to a CFG in the standard dialect. This is achieved by passing loop-carried
values as block arguments to the loop condition block. This block dominates
both the loop body and the block immediately following the loop, so the
arguments of this block are remain visible there.
Differential Revision: https://reviews.llvm.org/D75513
to allow use by a future replacment function.
Summary: [Refactor] Promote nameless lambda to fully named function, allowing easy replacement in following patch.
Subscribers: krytarowski, libcxx-commits
Tags: #libc
Differential Revision: https://reviews.llvm.org/D75480
```
// clang -c -gdwarf-5 a.s -o a.o
.section .init; ret
.text; ret
```
.debug_info contains DW_AT_ranges and llvm-dwarfdump will report
a verification error because .debug_rnglists does not exist (not
implemented).
This patch generates .debug_rnglists for assembly files.
emitListsTableHeaderStart() in DwarfDebug.cpp can be shared with
MCDwarf.cpp. Because CodeGen depends on MC, I move the function to
MCDwarf.cpp
Reviewed By: probinson
Differential Revision: https://reviews.llvm.org/D75375
Summary:
Follow up from D75377. If the subvector is byte sized and the
index is aligned to the subvector size, we can shrink the load.
Reviewers: spatel, RKSimon
Reviewed By: RKSimon
Subscribers: dbabokin, hiraditya, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D75434
The build_vector needs to be the only user of the data, but the
chain will likely have another use. So we can't make sure the
build_vector is the only user of the node.
The expected output is erroneous and will be corrected alongside a fix
to ensure stack arguments are widened to register width before writing
to the parameter save area.
MLIR ExecutionEngine and derived tools (e.g., mlir-cpu-runner) would trigger an
assertion inside ORC JIT while ExecutionEngine is being destructed after a
failed linking due to a missing function definition. The reason for this is the
JIT lookup that may return an Error referring to strings stored internally by
the JIT. If the Error outlives the ExecutionEngine, it would want have a
dangling reference, which is currently caught by an assertion inside JIT thanks
to hand-rolled reference counting. Rewrap the error message into a string
before returning.
Differential Revision: https://reviews.llvm.org/D75508
Some attribute kinds are not supported as "value" attributes of
`llvm.mlir.constant` when translating to LLVM IR. We were correctly reporting
an error, but continuing the translation using an "undef" value instead,
leading to a surprising mix of error messages and output IR. Abort the
translation after the error is reported.
Differential Revision: https://reviews.llvm.org/D75450
On SystemZ there are a set of "access registers" that can be copied in and
out of 32-bit GPRs with special instructions. These instructions can only
perform the copy using low 32-bit parts of the 64-bit GPRs. However, the
default register class for 32-bit integers is GRX32, which also contains the
high 32-bit part registers.
In order to never end up with a case of such a COPY into a high reg, this
patch adds a new simple pre-RA pass that selects such COPYs into target
instructions.
This pass also handles COPYs from CC (Condition Code register), and COPYs to
CC can now also be emitted from a high reg in copyPhysReg().
Fixes: https://bugs.llvm.org/show_bug.cgi?id=44254
Review: Ulrich Weigand.
Differential Revision: https://reviews.llvm.org/D75014
While we have some tests for this command already, they are very vague.
This is not surprising -- it's hard to make strict assertions about the
assembly if your input is a c++ source file. This means that the tests
can more-or-less only detect when the command breaks completely, and not
when there is a subtle change in meaning due to e.g. a code refactor --
which is something that I am getting ready to do.
This tests in this patch create binaries with well known data (via assembler
and yaml2obj). This means that we are able to make precise assertions
about the text that lldb is supposed to print. As some of the features
of this command are only available with a real process, I use a minidump
core file to create a sufficiently realistic process object.
Summary:
The argument that sets the prefetch type of a prefetch intrinsic must
be an immediate value.
Reviewers: andwar, sdesmalen, efriedma
Subscribers: tschuett, hiraditya, rkruppe, psnobl, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D75482
Use MIOperand in collectLocalKilledOperands to make the search
global, as we already have to search for global uses too. This
allows us to delete more dead code when tail predicating.
Differential Revision: https://reviews.llvm.org/D75167
In RDA, check against the already decided dead instructions when
looking at users. This allows an instruction to be removed if it
has multiple users, but they're all dead.
This means that IT instructions can be considered killed once all
the itstate using instructions are dead.
Differential Revision: https://reviews.llvm.org/D75245
SUMMARY:
1.if there is a gap between the end virtual address of one section and the beginning virtual address of the next section, the XCOFFObjectWriter.cpp will hit a assert.
2.as discussed in the patch https://reviews.llvm.org/D66969,
since implemented the function description. We can output the raw object data for function.
we need to create a test for raw text section content and test section header for xcoff object file.
Reviewer: daltenty,hubert.reinterpretcast,jasonliu
Differential Revision: https://reviews.llvm.org/D71845
Pickup the default crt and libs when the target is musl.
Resubmitting after updating the testcase.
Differential Revision: https://reviews.llvm.org/D75139
Summary:
This revision fixes a -Wzero-length-array compile error that
caused e459596917 which reverted
78f9e5d098.
Also fixes a struct vs class mismatch that broke compilation with
-Werror for Windows that caused
57397eba7a.
This revision adds padding for 1-D Vector in the common case of x86
execution with a stadard data layout. This supports properly interfacing
codegen with arrays of e.g. `vector<9xf32>`.
Such vectors are already assumed padded to the next power of 2 by LLVM
codegen with the default x86 data layout:
```
define void @test_vector_add_1d_2_3(<3 x float>* nocapture readnone %0,
<3 x float>* nocapture readonly %1, i64 %2, i64 %3, i64 %4, <3 x float>*
nocapture readnone %5, <3 x float>* nocapture readonly %6, i64 %7, i64
%8, i64 %9, <3 x float>* nocapture readnone %10, <3 x float>* nocapture
%11, i64 %12, i64 %13, i64 %14) local_unnamed_addr {
%16 = getelementptr <3 x float>, <3 x float>* %6, i64 1
%17 = load <3 x float>, <3 x float>* %16, align 16
%18 = getelementptr <3 x float>, <3 x float>* %1, i64 1
%19 = load <3 x float>, <3 x float>* %18, align 16
%20 = fadd <3 x float> %17, %19
%21 = getelementptr <3 x float>, <3 x float>* %11, i64 1
```
The pointer addressing a `vector<3xf32>` is assumed aligned `@16`.
Similarly, the pointer addressing a `vector<65xf32>` is assumed aligned
`@512`.
This revision allows using objects such as `vector<3xf32>` properly with
the standard x86 data layout used in the JitRunner. Integration testing
is done out of tree, at the moment such testing fails without this
change.
Differential Revision: https://reviews.llvm.org/D75459
This revision adds a static `mlir_c_runner_utils_static` library
for the sole purpose of being linked into `mlir_runner_utils` on
Windows.
It was previously reported that:
```
`add_llvm_library(mlir_c_runner_utils SHARED CRunnerUtils.cpp)`
produces *only* a dll on windows, the linking of mlir_runner_utils fails
because target_link_libraries is looking for a .lib file as opposed to a
.dll file. I think this may be a case where either we need to use
LINK_LIBS or explicitly build a static lib as well, but I haven't tried
either yet.
```
The incoming back chain slot was implicitly allocated whenever a GPR was
saved in SystemZFrameLowering::getRegSpillOffset(), but in cases where no
GPRs were saved/restored this did not take effect.
Review: Ulrich Weigand
Differential Revision: https://reviews.llvm.org/D75367
Stefan Stipanovic