This commit adds a boolean parameter that allows downstream users to
disable the verification when translating an MLIR module to LLVM IR.
This is helpful for debugging broken LLVM IR modules post translation.
This patch adds support for computing bounds for semi-affine mod
expression to FlatLinearConstraints. This is then enabled within the
ScalableValueBoundsConstraintSet to allow computing the bounds of
scalable remainder loops.
E.g. computing the bound of something like:
```
// `1000 mod s0` is a semi-affine.
#remainder_start_index = affine_map<()[s0] -> (-(1000 mod s0) + 1000)>
#remaining_iterations = affine_map<(d0) -> (-d0 + 1000)>
%0 = affine.apply #remainder_start_index()[%c8_vscale]
scf.for %i = %0 to %c1000 step %c8_vscale {
%remaining_iterations = affine.apply #remaining_iterations(%i)
// The upper bound for the remainder loop iterations should be:
// %c8_vscale - 1 (expressed as an affine map,
// affine_map<()[s0] -> (s0 * 8 - 1)>, where s0 is vscale)
%bound = "test.reify_bound"(%remaining_iterations) <{scalable, ...}>
}
```
There are caveats to this implementation. To be able to add a bound for
a `mod` we need to assume the rhs is positive (> 0). This may not be
known when adding the bounds for the `mod` expression. So to handle this
a constraint is added for `rhs > 0`, this may later be found not to hold
(in which case the constraints set becomes empty/invalid).
This is not a problem for computing scalable bounds where it's safe to
assume `s0` is vscale (or some positive multiple of it). But this may
need to be considered when enabling this feature elsewhere (to ensure
correctness).
In this case the union inside of the `parser::DefinedOperator` contains
a string name instead of the expected
`parser::DefinedOperator::IntrinsicOperator`. This led to a
`std::abort`.
This patch adapts the code so that if it contains a string name we emit
a semantic error.
This patch uses the ExtractFromEnd VPInstruction opcode
to extract the value of a FOR to be used as resume value for the ph in
the scalar loop.
It adds a new live-out that temporarily wraps the FOR phi in the scalar
loop. fixFixedOrderRecurrence will process live outs for fixed order
recurrence phis by creating a new phi node in the scalar preheader,
using the generated value for the live-out as incoming value from the
middle block and the original start value as incoming value for the
other edge. Creation of the phi in the preheader, as well as updating
the phi in the scalar loop will also be moved to VPlan in the future,
eventually retiring fixFixedOrderRecurrence
Depends on https://github.com/llvm/llvm-project/pull/93395
PR: https://github.com/llvm/llvm-project/pull/93396
For example:
clang\test\OpenMP\task_codegen.cpp: 0m29.570s -> 0m0.159s
clang\test\Driver: 4m55.917s -> 1m48.053s
Most win from big files.
---------
Co-authored-by: klensy <nightouser@gmail.com>
The pass constructor can be generated automatically by tablegen.
This pass is module-level and runs on all instances of target operations
inside of it and so does not need any modification to support
alternative top-level operations.
The PR adds the support of CoreDump debugging for RISC-V 64. It
implements new `RegisterContextCorePOSIX_riscv64` class.
Also, the contribution fixes `GetRegisterCount()` ->
`GetRegisterSetCount()` misprint in
`RegisterContextPOSIX_riscv64::GetRegisterSetCount()` method, which
leaded to `set && "Register set should be valid."` assertion during
`register info aX` command call.
The patch was tested (on coredumps generated for simple Integer/FP
calculation code) for _cross x86_64 -> RISCV_ and _native RISCV_ LLDB
builds. There were performed basic LLDB functionality tests, such as:
- CoreDump file load
- Backtrace / frames
- GP/FP registers read/info/list
- Basic switch between threads
- Disassembler code
- Memory regions read / display
Do not erase Builder when the first check fails because it could succeed
on the second stack frame.
The problem was that `InnerMatcher.matches` erases the bindings when it
returns false. The appropriate solution is to pass a copy of the
bindings, similar to what `matchesFirstInRange` does.
Only with SPV_INTEL_arbitrary_precision_integers SPIR-V Backend creates
arbitrary sized integer types (<= 64 bits). Without such extension and
according to the SPIR-V specification
`SPIRVGlobalRegistry::getOpTypeInt()` rounds integer sizes other than
8,16,32,64 up, to one of defined by the specification sizes. For the
`DuplicateTracker` class this means that several original LLVM types
(e.g., i2, i4) map to the same "OpTypeInt 8" instruction. This breaks
`DuplicateTracker`'s logic and leads to generation of invalid SPIR-V
code eventually.
For example,
```
define spir_func void @foo(i2 %a, i4 %b) {
entry:
%res2 = tail call i2 @llvm.bitreverse.i2(i2 %a)
%res4 = tail call i4 @llvm.bitreverse.i4(i4 %b)
ret void
}
declare i2 @llvm.bitreverse.i2(i2)
declare i4 @llvm.bitreverse.i4(i4)
```
after translation to SPIR-V would fail during validation (`spirv-val`)
due to two `OpTypeInt 8 0` instructions.
This PR fixes the issue by changing source LLVM type according to the
SPIR-V type that will be used in the emitted code.
This option was added in 3b79b2ab4e35353e63ba323a3de4b0a70c61a5f1 with
the comment:
> I had SROA implemented this way a long time ago and due to the
> overwhelming bugs that surfaced, moved to a much more relaxed
> variant. Richard Smith would like to understand the magnitude
> of this problem and it seems fairly harmless to keep some
> flag-controlled logic to get the extremely strict behavior here.
> I'll remove it if it doesn't prove useful.
As far as I know, it did not prove useful, so I'm removing it now.
With constant GEPs canonicalized to i8, GEPs that only temporarily go
out of bounds during the offset calculation do not naturally occur
anymore anyway.
flang/runtime/time-intrinsic.cpp:403:19: error: comparison of
integers of different signs: 'clock_t' (aka 'unsigned long') and
'int' [-Werror,-Wsign-compare]
if (times(&tms) != -1) {
This patch moves language- and target-specific functions out of
`SemaDeclAttr.cpp`. As a consequence, `SemaAVR`, `SemaM68k`,
`SemaMSP430`, `SemaOpenCL`, `SemaSwift` were created (but they are not
the only languages and targets affected).
Notable things are that `Sema.h` actually grew a bit, because of
templated helpers that rely on `Sema` that I had to make available from
outside of `SemaDeclAttr.cpp`. I also had to left CUDA-related in
`SemaDeclAttr.cpp`, because it looks like HIP is building up on top of
CUDA attributes.
This is a follow-up to #93179 and continuation of efforts to split
`Sema` up. Additional context can be found in #84184 and #92682.
Fixes a crash uncovered by
[pr77666.f90](https://github.com/llvm/llvm-test-suite/blob/main/Fortran/gfortran/regression/gomp/pr77666.f90)
in the test suite when delayed privatization is enabled by default.
In particular, whenever `PrivCB` (the callback responsible for
generating privatizaiton logic for an OMP variable) generates a
multi-block privatization region, the insertion point diverges: the BB
component of the IP can become a different BB from the parent block of
the instruction iterator component of the IP. This PR updates the IP to
make sure that the BB is the parent block of the instruction iterator.
Add check of number of operands for concat_vectors being equal to 2.
This can
avoid crash if there are more than 2 operands for concat_vectors and
operand 0 & 1 are undef value.
Fixes: 5ee580bbfb11d781c220c19416c1a97b657e039a
5ee580bbfb11d781c220c19416c1a97b657e039a does not ensure that
UseAssemblerInfoForParsing is re-enabled. This is benign but not good.
In ValidateMemRefs pass, when we validate references in the form of
`Symbol + Addend`, we should check `Symbol` not `Symbol + Addend`
against aliasing a jump table.
Recommitting with a modified test case:
https://github.com/llvm/llvm-project/pull/88838
Co-authored-by: sinan <sinan.lin@linux.alibaba.com>
In a simple case like this:
```
program test
integer :: u(120, 2)
u(1:120,1:2) = u(1:120,1:2) + 2
end program
```
Flang is creating a copy loop with fir.array_coor using
a result of fir.embox inserted before the loop. This results in split
address computations before and inside the loop, which can be seen
as many more arithmetic operations than required after converting
FIR to LLVM dialect. Even though LLVM SROA/mem2reg are able
to optimize the temporary descriptor, and then LICM is able to hoist
the invariant computations, we seem to get better mix of LLVM dialect
operations after FIR-to-LLVM codegen. This may also slightly reduce
the compilation time taken by LLVM to optimize the generate LLVM IR.
This may also slightly reduce the time spent by FIR AliasAnalysis
to reach the memory reference source.
Similar to commit 245491a9f384e4c53421196533c2a2b693efaf8d for DwarfDebug.
This completely disables the expensive MCFragment walk code in
`AttemptToFoldSymbolOffsetDifference` when compiling sqlite3.i for
macOS.
In the future, we should try enabling the MCFragment walk only for
constructs like `.if . -_start == 1` and `.subsection a-b` and
remove these `setUseAssemblerInfoForParsing`.
Update LAA to use PSE::getSymbolicMaxBackedgeTakenCount which returns
the minimum of the countable exits.
When analyzing dependences and computing runtime checks, we need the
smallest upper bound on the number of iterations. In terms of memory
safety, it shouldn't matter if any uncomputable exits leave the loop,
as long as we prove that there are no dependences given the minimum of
the countable exits. The same should apply also for generating runtime
checks.
Note that this shifts the responsiblity of checking whether all exit
counts are computable or handling early-exits to the users of LAA.
Depends on https://github.com/llvm/llvm-project/pull/93498
PR: https://github.com/llvm/llvm-project/pull/93499
This is a follow-up of
https://github.com/llvm/llvm-project/pull/92328#issuecomment-2145849441
Clang attaches `DW_AT_declaration` to static inline data members and
`dsymutil` indexes these constants. Skipping these caused the expression
evaluator to fail to find such constants when using DWARFv5.
Fixes `TestConstStaticIntegralMember.py` on DWARFv5.
Very minor change to help message on `process save-core`. Adds space
between two sentences explaining the `-p` option:
"Specify a plugin name to create the core file.This allows core files to
be saved in different formats."
-->
"Specify a plugin name to create the core file. This allows core files
to be saved in different formats."
Before:
```
(lldb) help process save-core
Save the current process as a core file using an appropriate file type.
Syntax: process save-core [-s corefile-style -p plugin-name] FILE
Command Options Usage:
process save-core [-p[<plugin>]] [-s <corefile-style>] <path>
-p[<plugin>] ( --plugin-name=[<plugin>] )
Specify a plugin name to create the core file.This allows core files to be saved in different formats.
-s <corefile-style> ( --style <corefile-style> )
Request a specific style of corefile to be saved.
Values: full | modified-memory | stack
This command takes options and free-form arguments. If your arguments resemble option specifiers (i.e., they start with a -
or --), you must use ' -- ' between the end of the command options and the beginning of the arguments.
```
After:
```
michristensen@devbig356 build/Debug » $HOME/llvm-sand/build/Debug/bin/lldb -x
(lldb) help process save-core
Save the current process as a core file using an appropriate file type.
Syntax: process save-core [-s corefile-style -p plugin-name] FILE
Command Options Usage:
process save-core [-p[<plugin>]] [-s <corefile-style>] <path>
-p[<plugin>] ( --plugin-name=[<plugin>] )
Specify a plugin name to create the core file. This allows core files to be saved in different formats.
-s <corefile-style> ( --style <corefile-style> )
Request a specific style of corefile to be saved.
Values: full | modified-memory | stack
This command takes options and free-form arguments. If your arguments resemble option specifiers (i.e., they start with a -
or --), you must use ' -- ' between the end of the command options and the beginning of the arguments.
```
To get the time trace of LTO in the gold plugin, now we can pass the
`time-trace=<time trace file>` as well as
`time-trace-granularity=<granularity>` flags to LLVMgold.
Note that we still have to populate `LTOConfig::TimeTraceEnabled` and
`LTOConfig::TimeTraceGranularity` because ThinLTO backend needs them.
