Bump (2023-12-15) #106
Merged
Bump (2023-12-15) #106
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
The file name is WS2_32.Lib in all the Windows SDK versions I looked at. You can get away with the incorrect casing on a case-insensitive file system but it can matter for cross-compilation.
… in the loop body (llvm#75423)
This commit adds relative TableGen definitions to parse the `[[gnu::no_stack_protector]]` attribute. This PR addresses issue llvm#75235.
…#74811) Buildbots reported: .../CommandLine.cpp:1626:13: error: variable 'NearestHandler' set but not used [-Werror,-Wunused-but-set-variable]
Extra libraries can show up here depending on how LLVM was configured, so just allow extra libraries to show up instead of expecting an exact list. Partially reverts d7aee33.
This patch replaces uses of StringRef::{starts,ends}with with
StringRef::{starts,ends}_with for consistency with
std::{string,string_view}::{starts,ends}_with in C++20.
I'm planning to deprecate and eventually remove
StringRef::{starts,ends}with.
This patch replaces uses of StringRef::{starts,ends}with with
StringRef::{starts,ends}_with for consistency with
std::{string,string_view}::{starts,ends}_with in C++20.
I'm planning to deprecate and eventually remove
StringRef::{starts,ends}with.
This patch replaces uses of StringRef::{starts,ends}with with
StringRef::{starts,ends}_with for consistency with
std::{string,string_view}::{starts,ends}_with in C++20.
I'm planning to deprecate and eventually remove
StringRef::{starts,ends}with.
This patch replaces uses of StringRef::{starts,ends}with with
StringRef::{starts,ends}_with for consistency with
std::{string,string_view}::{starts,ends}_with in C++20.
I'm planning to deprecate and eventually remove
StringRef::{starts,ends}with.
This patch replaces uses of StringRef::{starts,ends}with with
StringRef::{starts,ends}_with for consistency with
std::{string,string_view}::{starts,ends}_with in C++20.
I'm planning to deprecate and eventually remove
StringRef::{starts,ends}with.
This patch replaces uses of StringRef::{starts,ends}with with
StringRef::{starts,ends}_with for consistency with
std::{string,string_view}::{starts,ends}_with in C++20.
I'm planning to deprecate and eventually remove
StringRef::{starts,ends}with.
Last `getline` call destroys `InputString`, and `finish` accesses dead `StringRef`. Detected with llvm#72677. Fixes https://lab.llvm.org/buildbot/#/builders/sanitizer-x86_64-linux-fast
…lvm#74989) Remove the part about implicit conversion from an iterator to a pointer. This part of the manual was written 14 years ago, in: llvm@37027c3 There do exist a type casting operator in `ilist` then: https://github.com/llvm/llvm-project/blob/37027c30ec526afe3bb571df6f8701bf0d322f22/llvm/include/llvm/ADT/ilist.h#L192-L194 But it has been remove since 2016: llvm@f197b1f So I think it makes sense to remove this part to avoid mislead new contributors.
Add the `dead_on_unwind` attribute, which states that the caller will not read from this argument if the call unwinds. This allows eliding stores that could otherwise be visible on the unwind path, for example: ``` declare void @may_unwind() define void @src(ptr noalias dead_on_unwind %out) { store i32 0, ptr %out call void @may_unwind() store i32 1, ptr %out ret void } define void @tgt(ptr noalias dead_on_unwind %out) { call void @may_unwind() store i32 1, ptr %out ret void } ``` The optimization is not valid without `dead_on_unwind`, because the `i32 0` value might be read if `@may_unwind` unwinds. This attribute is primarily intended to be used on sret arguments. In fact, I previously wanted to change the semantics of sret to include this "no read after unwind" property (see D116998), but based on the feedback there it is better to keep these attributes orthogonal (sret is an ABI attribute, dead_on_unwind is an optimization attribute). This is a reboot of that change with a separate attribute.
Add `num-threads` option to the `-convert-scf-to-openmp` pass, allowing to set the number of threads to be used in the `omp.parallel` to a fixed value.
Is it redundant with `FloatProperties::EXPONENT_WIDTH` and does bear its weight.
Use the iterator returned by MapVector::insert to update the value in the map, instead of a second redundant map lookup.
…-streaming function" (llvm#75449) Reverts llvm#74064
- Precommit of tests from llvm#71360. - Replace `undef` pointer operands and add stores to avoid the loads being optmized away.
It prevents LLVM from being linked with LLD at least on Windows, with
errors like this:
```
= note: ld.lld: error: duplicate symbol: vtable for llvm::FormalArgHandler
>>> defined at librustc_llvm-a81737dd65a7c126.rlib(M68kCallLowering.cpp.obj)
>>> defined at librustc_llvm-a81737dd65a7c126.rlib(PPCCallLowering.cpp.obj)
```
Binutils linker also complains about this, but only with warnings.
`FormalArgHandler` has a base class `M68kIncomingValueHandler` which
doesn't have a virtual method `markPhysRegUsed` like
`IncomingValueHandler`s for all other targets including PPC, so it
results in a conflict.
The simplest fix is to rename the `FormalArgHandler` structure (rather
than to add virtual methods for compatibility).
cc rust-lang/rust#107668
Add missing AVX512 Z prefix to conform to the standard naming convention and simplify matching in X86FoldTablesEmitter::addBroadcastEntry etc.
This reverts commit eb05d7a.
…NFC (llvm#75544) These test cases where intended to get a single vsetvli by using the vmv.s.x intrinsic with the same LMUL as the reduction. This works for FP, but does not work for integer. I believe llvm#71501 will break this for FP too. Hopefully the vsetvli pass can be taught to fix this.
Remove calls to CreatePointerCast which are just doing no-op ptr-to-ptr bitcasts. Opaque ptr cleanup effort (NFC).
) If we're lowering a fixed length vector load or store which happens to exactly VLEN in size (when VLEN is exactly known), we can use a whole register load or store instead of the unit strided variants. This doesn't require a vsetvli in some cases, allows additional flexibility of vsetvli cases in others, and doesn't have a runtime dependency on the value of VL.
Issue is covered by existing test llvm/test/Transforms/SLPVectorizer/RISCV/phi-const.ll See issue llvm#75632 for ideas for how we could catch these more easily in the future.
As suggested post-commit for a002271, remove the stale comment, SetVector is no longer used here.
…5554) This patch adds in validation at two different levels that address annotations are page aligned. This is necessary as otherwise the mmap calls will fail as MAP_FIXED/MAP_FIXED_NOREPLACE require page aligned addresses. This happens silently in the subprocess. This patch adds validation at snippet parsing time to give feedback to the user and also adds asserts at code generation/address usage time to ensure that other users of the Exegesis APIs conform to the same requirements.
`baseAddr` is not used in `genBaseBoundsOps` just remove it.
…ge code models (llvm#75542) In llvm#74514 and llvm#74778 we marked various instrumentation-added sections as large. This causes an extra PT_LOAD segment if using the small code model. Since people using the small code model presumably aren't hitting relocation limits, disable this when using the small code model to avoid the extra segment. This uses Module::getCodeModel() which isn't necessarily reliable since it reads module metadata (which right now only the clang frontend sets), but it would be nice to get to a point where we reliably put this sort of information (e.g. PIC/code model/etc) in the IR. This requires duplicating the existing tests since opt/llc currently don't set these metadata. If we get to a point where they do set the code model metadata based on command line arguments then we can deduplicate these tests.
Updates the vectorisation of 1D depthwise convolution when flattening the channel dimension (introduced in llvm#71918). In particular - how the convolution filter is "flattened". ATM, the vectoriser will use `vector.shape_cast`: ```mlir %b_filter = vector.broadcast %filter : vector<4xf32> to vector<3x2x4xf32> %sc_filter = vector.shape_cast %b_filter : vector<3x2x4xf32> to vector<3x8xf32> ``` This lowering is not ideal - `vector.shape_cast` can be convenient when it's folded away, but that's not happening in this case. Instead, this patch updates the vectoriser to use `vector.shuffle` (the overall result is identical): ```mlir %sh_filter = vector.shuffle %filter, %filter [0, 1, 2, 3, 0, 1, 2, 3] : vector<4xf32>, vector<4xf32> %b_filter = vector.broadcast %sh_filter : vector<8xf32> to vector<3x8xf32> ```
… NFC. (llvm#75172) This shouldn't have any user visible effect, but makes the logic within the linker implementation more explicit. Note how DWARF debug info sections were retained even if enabling a link with PDB info only; that behaviour is preserved.
Don't treat the options as unique enum items, but more as flags that can be composed, like the /opt: options. This still only processes the last option on the command line though, so the behaviour should still remain exactly as it was, in all corner cases.
Most option handling is like it was before; the last /debug: option takes effect. However, the options /debug:dwarf or /debug:symtab don't reset all flags into the specific behaviour they chose before - e.g. if an earlier option enables writing a PDB, a later /debug:dwarf or /debug:symtab doesn't disable that. This allows combining these options with options for controlling PDB writing, for finetuning what is done.
These allow tweaking what gets implied by /debug and /debug:dwarf.
…75181) This allows avoiding including some stray DWARF sections (e.g. from toolchain provided files), when writing a PDB file. While that probably could be considered reasonable default behaviour, PDB writing and including DWARF sections are two entirely orthogonal concepts, and GNU ld (which can generate PDB files these days) does include DWARF unless -S/-s is passed, when creating a PDB.
…name (llvm#75389) If passing the windres option --preprocessor, the default arguments "-E -xc -DRC_INVOKED" aren't passed. If these are passed explicitly by the user via --preprocessor-arg instead, we need to make sure that "-xc" is passed before the input filename, as this compiler/preprocessor option only has an effect on input files that follow it. This fixes one of the issues with llvm-windres observed in msys2/MINGW-packages#19157.
…5390) The llvm::sys::ExecuteAndWait function doesn't resolve the file to be executed from $PATH - i.e. it is similar to execv(), not execvp(). Due to this, specifying a --preprocessor argument to llvm-windres only worked if it specified an absolute path to the preprocessor executable. This was observed as one of the issues in msys2/MINGW-packages#19157. Before d2fa6b6, this usage of --preprocessor seemed to work, because the first argument of Args[] was ignored and llvm-windres just executed the autodetected clang executable regardless. Also improve the error messages printed if preprocessing failed. (If the preprocessor executable was started but itself returned an error, we don't get any error string.)
It is beneficial to preallocate a certain number of pages in the linear memory (i. e. use the "minimum" field of WASM memories) so that fewer "memory.grow"s are needed at startup. So far, the way to do that has been to pass the "--initial-memory" option to the linker. It works, but has the very significant downside of requiring the user to know the size of static data beforehand, as it must not exceed the number of bytes passed-in as "--initial-memory". The new "--initial-heap" option avoids this downside by simply appending the specified number of pages to static data (and stack), regardless of how large they already are. Ref: emscripten-core/emscripten#20888.
mgehre-amd
force-pushed
the
matthias.bump
branch
from
bf99b62 to
b1e618b
Compare
ehsan-toosi
approved these changes
Feb 27, 2024
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Bump to