Hi all,
This patch is a follow-up of #79101. It migrates logic from
`visitVSELECT` to `visitVP_SELECT` to simplify `vp.select`. With this
patch we can do the following combinations:
```
vp.select undef, T, F --> T (if T is a constant), F otherwise
vp.select <condition>, undef, F --> F
vp.select <condition>, T, undef --> T
vp.select false, T, F --> F
vp.select <condition>, T, T --> T
```
I'm a total newbie to llvm and I'm sure there's room for improvements in
this patch. Please let me know if you have any advice. Thank you in
advance!
This is an extension to 07151f0241d3f893cb36eb2dbc395d4098f74a87 which handled SandyBridge so we at least model the regression identified in #14640
Confirmed by Agner + uops.info/uica (SkylakeServer also had an incorrect use of Port015 instead of just Port01)
I raised #86669 as a proposal for a 'x86 unfold' pass that can unfold these (if we have the free registers) driven by the scheduler model.
It's a common pattern that we have a machine type, but we don't care
which ARM64* platform we're dealing with. We already have
isAnyArm64 for that, but it does not fit cases where we use a switch
statement. With this helper, it's easy to simplify such cases by using
Triple::ArchType instead of machine type.
Empty structs are ignored for parameter passing purposes, but va_arg was
incrementing the pointer anyway for that the size of empty struct in c++
is 1 byte, which could lead to va_list getting out of sync. Fix#86057.
One or two of the tests need slight tweaks to make them pass when
building with musl.
This patch is a re-application of b61fb18 which was reverted in 0847c90
because it broke the build.
rdar://118885724
Co-authored-by: Alastair Houghton <ahoughton@apple.com>
Reenables b31414bf4f9898f7817a9fcf8a91f62ec26f3eaf.
Also adds a new warning for missing `--symbol-graph-dir` arg when
`--emit-extension-symbol-graphs` is provided. This also reverts the
commit that removed.
We were generating "" (the empty string) as an alias for a bunch of FLAT
instructions, which had no effect except to cause tablegen to generate
some very long if-else chains in the generate AsmMatcher.
We required the file name of an 'importable module unit' should end
with .cppm (or .ccm, .cxxm, .c++m).
But the driver can accept '-fmodule-output' for files with normal
suffixes (e.g., .cpp). This is somewhat inconsistency.
In this patch, we only claim the option `-fmodule-output` is used if
the type of the input file is modules related. Then now the compiler
will emit 'unused argument' warnings if the input file is not modules
related.
This tries to fill in the basic vector handling for sadd_sat/uadd_sat
and ssub_sat/usub_sat. It just handles the basics, marking legal types
and clamping illegally sized vectors to legal ones.
We have many problems to use CodeView for a win32-elf target, e.g.,
#87140 and `error: .seh_* directives are not supported on this target`.
Fixes: #87140
Now the `DeclContext::noload_lookup()` asserts that 'this' is not a
transparent context. However, this is not consistent with
`DeclContext::lookup()`, which will lookup into its parent context if
'this' is a transparent context.
This patch makes the behavior of `DeclContext::noload_lookup()` to be
consistent with `DeclContext::lookup()`, to lookup into the parent
context if 'this' is a transparent context.
This patch extract logics in ASTWriter::WriteASTCore about writing decls
and types into a standalone function. The WriteASTCore function is
pretty long and hard to read. It should be helpful for readability to extract the common
logics into a standalone function.
This is also helpful for further changes e.g., removing unreachable
declarations.
expand-large-fp-convert cannot handle vector types.
If overly large vector element types survive into
isel, they will likely be scalarized there, but since
isel cannot handle scalar integer types of that size,
it will assert.
Handle vector types in expand-large-fp-convert by
scalarizing them and then expanding the scalar type
operation. For large vectors, this results in a
*massive* code expansion, but it's better than
asserting.
`and/or/xor` operations can each be changed to sum of logical
operations including operators other than themselves.
`x&y -> (x|y) ^ (x^y)`
`x|y -> (x&y) | (x^y)`
`x^y -> (x|y) ^ (x&y)`
if left of condition of `SelectInst` is `and/or/xor` logical
operation and right is equal to `0, -1`, or a `constant`, and
if `TrueVal` consist of `and/or/xor` logical operation then we
can optimize this case.
This patch implements this combination.
Proof: https://alive2.llvm.org/ce/z/WW8iRR
Fixes https://github.com/llvm/llvm-project/issues/71792.
Recurrencies in the call graph (even if they are not executed)
prevent computing the minimal stack size required for a kernel
execution. This change disables some functionality of F18 IO
to avoid recursive calls. A couple of functions are rewritten
to work without using recursion.
https://github.com/llvm/llvm-project/pull/70762 added support for new
loop attribute [[clang::code_align()]].
This patch fixes bugs for the test cases below that misses diagnostics due to discontinue to while loop during checking duplicate vs conflicting code_align attribute values in routine CheckForDuplicateLoopAttrs().
[[clang::code_align(4)]]
[[clang::code_align(4)]]
[[clang::code_align(8)]]
for(int I=0; I<128; ++I) { bar(I); }
[[clang::code_align(4)]]
[[clang::code_align(4)]]
[[clang::code_align(8)]]
[[clang::code_align(32)]]
for(int I=0; I<128; ++I) { bar(I); }
Support generating dSYM companion files for (non-Darwin) firmware
environments by considering the binary component of the triple in
addition to the OS component.
rdar://125629792
Before this patch, the size of the reduced BMI may be large than the
full BMI when the source codes is pretty small. This violates the design
principles. The root cause is an oversight that we skipped something
in full BMI but forgot to make it in reduced BMI.
The unstable partition in partitionRels might reverse IRELATIVE
relocations, so stable_partition in computeRels would lead to IRELATIVE
relocations ordered by decreasing offset. Use stable_partition in
partitionRels to get IRELATIVE relocations ordered by increasing offset.
Re-organizes the tables that listed libc's support for math functions,
and adds two new columns to the tables indicating where the respective
function definitions and error handling methods are located in the C23
standard draft WG14-N3096.
- The opcode of the mina.fmt and max.fmt is documented wrong, the
object code compiled from the same assembly with LLVM behaves
differently than one compiled with GCC and Binutils.
- Modify the opcodes to match Binutils. The actual opcodes are as
follows:
{5,3} | bits {2,0} of func
| ... | 100 | 101 | 110 | 111
-----+-----+-----+-----+-----+-----
010 | ... | min | mina | max | maxa
For pragma diagnostic mappings, we always write/read `SourceLocation`
with offset 0. This is equivalent to just writing a `FileID`, which is
exactly what this patch starts doing.
Originally reviewed here: https://reviews.llvm.org/D137213
`linalg.generic` ops with sparse tensors do not necessarily bufferize to
element-wise access, because insertions into a sparse tensor may change
the layout of (or reallocate) the underlying sparse data structures.
Both `std::distance` or `ranges::distance` are inefficient for
non-sized ranges. Also, calculating the range using `int` type is
seriously problematic.
This patch avoids using `distance` and calculation of the length of
non-sized ranges.
Fixes#86833.
The tosa-infer-shapes pass inserts tensor.cast operations to mediate
refined result types with consumers whose types cannot be refined. This
process interferes with how types are refined in tosa.while_loop body
regions, where types are propagated speculatively (to determine the
types of the tosa.yield terminator) and then reverted.
The new tosa.cast operations result in a crash due to not having types
associated to them for the reversion process.
This change modifies the shape propagation behavior so that the
introduction to tensor.cast operations behaves better with this type
reversion process. The new behavior is to only introduce tensor.cast
operations once we wish to commit the newly computed types to the IR.
This is an example causing the crash:
```mlir
func.func @while_dont_crash(%arg0 : tensor<i32>) -> (tensor<*xi32>) {
%0 = tosa.add %arg0, %arg0 : (tensor<i32>, tensor<i32>) -> tensor<*xi32>
%1 = tosa.while_loop (%arg1 = %0) : (tensor<*xi32>) -> tensor<*xi32> {
%2 = "tosa.const"() <{value = dense<3> : tensor<i32>}> : () -> tensor<i32>
%3 = tosa.greater_equal %2, %arg1 : (tensor<i32>, tensor<*xi32>) -> tensor<*xi1>
tosa.yield %3 : tensor<*xi1>
} do {
^bb0(%arg1: tensor<*xi32>):
// Inferrable operation whose type will refine to tensor<i32>
%3 = tosa.add %arg1, %arg1 : (tensor<*xi32>, tensor<*xi32>) -> tensor<*xi32>
// Non-inferrable use site, will require the cast:
// tensor.cast %3 : tensor<i32> to tensor<*xi32>
//
// The new cast operation will result in accessing undefined memory through
// originalTypeMap in the C++ code.
"use"(%3) : (tensor<*xi32>) -> ()
tosa.yield %3 : tensor<*xi32>
}
return %1 : tensor<*xi32>
}
```
The `tensor.cast` operation inserted in the loop body causes a failure
in the code which resets the types after propagation through the loop
body:
```c++
// The types inferred in the block assume the operand types specified for
// this iteration. We need to restore the original types to ensure that
// future iterations only use the already specified types, not possible
// types from previous iterations.
for (auto &block : bodyRegion) {
for (auto arg : block.getArguments())
arg.setType(originalTypeMap[arg]);
for (auto &op : block)
for (auto result : op.getResults())
result.setType(originalTypeMap[result]); // problematic access
}
```
---------
Co-authored-by: Spenser Bauman <sabauma@fastmail>
This patch introduces a new `IterationMarker` enum (happy to take
alternative name suggestions), which callbacks, like the one in
`SymbolFileDWARFDebugMap::ForEachSymbolFile`, can return in order to
indicate whether the caller should continue iterating or bail.
For now this patch just changes the `ForEachSymbolFile` callback to use
this new enum. In the future we could change the various
`DWARFIndex::GetXXX` callbacks to do the same.
This makes the callbacks easier to read and hopefully reduces the chance
of bugs like https://github.com/llvm/llvm-project/pull/87177.
Currently, the bounds check in `std::ranges::advance(it, n, s)` is done
_before_ `n` is checked. This results in one extra, unneeded bounds
check.
Thus, `std::ranges::advance(it, 1, s)` currently is _not_ simply
equivalent to:
```c++
if (it != s) {
++it;
}
```
This difference in behavior matters when the check involves some
"expensive" logic. For example, the `==` operator of
`std::istreambuf_iterator` may actually have to read the underlying
`streambuf`.
Swapping around the checks in the `while` results in the expected
behavior.
