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
Response files where not being correctly read on Windows, this change
fixes the issue and adds some tests.
Differential Revision: https://reviews.llvm.org/D69665
Summary:
This patch introduces the `clang_analyzer_isTainted` expression inspection
check for checking taint.
Using this we could query the analyzer whether the expression used as the
argument is tainted or not. This would be useful in tests, where we don't want
to issue warning for all tainted expressions in a given file
(like the `debug.TaintTest` would do) but only for certain expressions.
Example usage:
```lang=c++
int read_integer() {
int n;
clang_analyzer_isTainted(n); // expected-warning{{NO}}
scanf("%d", &n);
clang_analyzer_isTainted(n); // expected-warning{{YES}}
clang_analyzer_isTainted(n + 2); // expected-warning{{YES}}
clang_analyzer_isTainted(n > 0); // expected-warning{{YES}}
int next_tainted_value = n; // no-warning
return n;
}
```
Reviewers: NoQ, Szelethus, baloghadamsoftware, xazax.hun, boga95
Reviewed By: Szelethus
Subscribers: martong, rnkovacs, whisperity, xazax.hun,
baloghadamsoftware, szepet, a.sidorin, mikhail.ramalho, donat.nagy,
Charusso, cfe-commits, boga95, dkrupp, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D74131
Forming subtract with overflow is beneficial on SystemZ, just like additions.
Review: Ulrich Weigand
Differential Revision: https://reviews.llvm.org/D75290
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: This patch adds a new way to query operand bundles of an llvm.assume that is much better suited to some users like the Attributor that need to do many queries on the operand bundles of llvm.assume. Some modifications of the IR like replaceAllUsesWith can cause information in the map to be outdated, so this API is more suited to analysis passes and passes that don't make modification that could invalidate the map.
Reviewers: jdoerfert, sstefan1, uenoku
Reviewed By: jdoerfert
Subscribers: hiraditya, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D75020
This patch adds a getPlan accessor to VPBlockBase, which finds the entry
block of the plan containing the block and returns the plan set for this
block.
VPBlockBase contains a VPlan pointer, but it should only be set for
the entry block of a plan. This allows moving blocks without updating
the pointer for each moved block and in the future we might introduce a
parent relationship between plans and blocks, similar to the one in LLVM IR.
Reviewers: rengolin, hsaito, fhahn, Ayal, dorit, gilr
Reviewed By: gilr
Differential Revision: https://reviews.llvm.org/D74445
Instead of a ExecutionContext*. All it needs is the target so it can
read the memory.
This removes some defensive checks from the function. I've added
equivalent checks to the callers in cases where a non-null target
pointer was not guaranteed to be available.
llvm/Support/Base64, fix its implementation and provide a decent test suite.
Previous implementation code was using + operator instead of | to combine
results, which is a problem when shifting signed values. (0xFF << 16) is
implicitly converted to a (signed) int, and thus results in 0xffff0000,
h is
negative. Combining negative numbers with a + in that context is not what we
want to do.
This is a recommit of 5a1958f267 with UB removved.
This fixes https://github.com/llvm/llvm-project/issues/149.
Differential Revision: https://reviews.llvm.org/D75057
Also adds a force-reduction-intrinsics option for testing, for forcing
the generation of reduction intrinsics even when the backend is not
requesting them.
Summary:
Since RangeDataVector is assumed to always be sorted we can treat it as
an flattened BST and augment it with additional information about the
ranges belonging to each "subtree". By storing the maximum endpoint in
every subtree we can query for intervals in O(log n) time.
Reviewers: labath, teemperor
Reviewed By: labath
Subscribers: jarin, JDevlieghere, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D74759
Summary:
If a command from a sourced file produces asynchronous output, this
output often does not make its way to the user. This happens because the
asynchronous output machinery relies on the iohandler stack to ensure
the output does not interfere with the things the iohandler is doing.
However, if this happens near the end of the command stream then by the
time the asynchronous output is produced we may already have already
started tearing down the sourcing session. Specifically, we may already
pop the relevant iohandler, leaving the stack empty.
This patch makes sure this kind of output gets printed by adding a
fallback to IOHandlerStack::PrintAsync to print the output directly if
the stack is empty. This is safe because if we have no iohandlers then
there is nothing to synchronize.
Reviewers: JDevlieghere, clayborg
Subscribers: lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D75454
and follow-ups:
a2ca1c2d "build: disable zlib by default on Windows"
2181bf40 "[CMake] Link against ZLIB::ZLIB"
1079c68a "Attempt to fix ZLIB CMake logic on Windows"
This changed the output of llvm-config --system-libs, and more
importantly it broke stand-alone builds. Instead of piling on more fix
attempts, let's revert this to reduce the risk of more breakages.
This reverts commit 0a9fc9233e.
Going to look at the asan failures.
I find the failures in the test suite weird, because they look
like compile time test and I don't understand how that can be
failing, but will have a brief look at that too.
Summary:
The define out of line refactor tool previously would copy the `virtual`, `override` and `final` specifier into the out of line method definition.
This results in malformed code as those specifiers aren't allowed outside the class definition.
Reviewers: hokein, kadircet
Reviewed By: kadircet
Subscribers: ilya-biryukov, MaskRay, jkorous, arphaman, kadircet, usaxena95, cfe-commits
Tags: #clang, #clang-tools-extra
Differential Revision: https://reviews.llvm.org/D75429
Summary:
LDRdPtr expanded from LDWRdPtr shouldn't define its second operand(SrcReg).
The second operand is its source register.
Add -verify-machineinstrs into command line of testcases can trigger this error.
Reviewers: dylanmckay
Reviewed By: dylanmckay
Subscribers: hiraditya, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D75437
This reverts commit 5aa57c2812.
The source code generated due to this ods change does not compile,
as it passes to few arguments to llvm::is_contained.
This makes -fno-common the default for all targets because this has performance
and code-size benefits and is more language conforming for C code.
Additionally, GCC10 also defaults to -fno-common and so we get consistent
behaviour with GCC.
With this change, C code that uses tentative definitions as definitions of a
variable in multiple translation units will trigger multiple-definition linker
errors. Generally, this occurs when the use of the extern keyword is neglected
in the declaration of a variable in a header file. In some cases, no specific
translation unit provides a definition of the variable. The previous behavior
can be restored by specifying -fcommon.
As GCC has switched already, we benefit from applications already being ported
and existing documentation how to do this. For example:
- https://gcc.gnu.org/gcc-10/porting_to.html
- https://wiki.gentoo.org/wiki/Gcc_10_porting_notes/fno_common
Differential revision: https://reviews.llvm.org/D75056
Sometimes we need to dump an object and build it again from a YAML
description produced. The problem is that obj2yaml does not dump some
of sections, like string tables and symbol tables.
Because of that yaml2obj implicitly creates them and sections created
are not placed at their original locations. They are added to the end of a section list.
That makes a preparing test cases task harder than it can be.
This patch teaches obj2yaml to dump parts of allocatable SHT_STRTAB, SHT_SYMTAB
and SHT_DYNSYM sections to print placeholders for them.
This also allows to preserve usefull parameters, like virtual address.
Differential revision: https://reviews.llvm.org/D74955
This patch adds support for dwarf emission/dumping part of debuginfo
generation for defaulted parameters.
Reviewers: probinson, aprantl, dblaikie
Reviewed By: aprantl, dblaikie
Differential Revision: https://reviews.llvm.org/D73462
Summary:
This is to avoid generating duplicate llvm.dbg.value instrinsic if it already exists after the Instruction.
Before inserting llvm.dbg.value instruction, LLVM checks if the same instruction is already present before the instruction to avoid duplicates.
Currently it misses to check if it already exists after the instruction.
flang generates IR like this.
%4 = load i32, i32* %i1_311, align 4, !dbg !42
call void @llvm.dbg.value(metadata i32 %4, metadata !35, metadata !DIExpression()), !dbg !33
When this IR is processed in llvm, it ends up inserting duplicates.
%4 = load i32, i32* %i1_311, align 4, !dbg !42
call void @llvm.dbg.value(metadata i32 %4, metadata !35, metadata !DIExpression()), !dbg !33
call void @llvm.dbg.value(metadata i32 %4, metadata !35, metadata !DIExpression()), !dbg !33
We have now updated LdStHasDebugValue to include the cases when instruction is already
followed by same dbg.value instruction we intend to insert.
Now,
Definition and usage of function LdStHasDebugValue are deleted.
RemoveRedundantDbgInstrs is called for the cleanup of duplicate dbg.value's
Testing:
Added unit test for validation
check-llvm
check-debuginfo (the debug info integration tests)
Reviewers: aprantl, probinson, dblaikie, jmorse, jini.susan.george
SouraVX, awpandey, dstenb, vsk
Reviewed By: aprantl, jmorse, dstenb, vsk
Differential Revision: https://reviews.llvm.org/D74030
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.
```
Summary:
This revision fixes a -Wzero-length-array compile error that
caused e459596917 which reverted
78f9e5d098.
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
Nicolas Vasilache