[pull] main from MaxMood96:main #743
Merged
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
![pull[bot]](https://avatars.githubusercontent.com/in/12910?s=60&v=4){kind=small}
Reviewed By: aartbik Differential Revision: https://reviews.llvm.org/D135692
…le_externally For a local linkage GlobalObject in a non-prevailing COMDAT, it remains defined while its leader has been made available_externally. This violates the COMDAT rule that its members must be retained or discarded as a unit. To fix this, update the regular LTO change D34803 to track local linkage GlobalValues, and port the code to ThinLTO (GlobalAliases are not handled.) This fixes two problems. (a) `__cxx_global_var_init` in a non-prevailing COMDAT group used to linger around (unreferenced, hence benign), and is now correctly discarded. ``` int foo(); inline int v = foo(); ``` (b) Fix llvm#58215: as a size optimization, we place private `__profd_` in a COMDAT with a `__profc_` key. When FuncImport.cpp makes `__profc_` available_externally due to a non-prevailing COMDAT, `__profd_` incorrectly remains private. This change makes the `__profd_` available_externally. ``` cat > c.h <<'eof' extern void bar(); inline __attribute__((noinline)) void foo() {} eof cat > m1.cc <<'eof' int main() { bar(); foo(); } eof cat > m2.cc <<'eof' __attribute__((noinline)) void bar() { foo(); } eof clang -O2 -fprofile-generate=./t m1.cc m2.cc -flto -fuse-ld=lld -o t_gen rm -fr t && ./t_gen && llvm-profdata show -function=foo t/default_*.profraw clang -O2 -fprofile-generate=./t m1.cc m2.cc -flto=thin -fuse-ld=lld -o t_gen rm -fr t && ./t_gen && llvm-profdata show -function=foo t/default_*.profraw ``` Reviewed By: tejohnson Differential Revision: https://reviews.llvm.org/D135427
Differential Revision: https://reviews.llvm.org/D135611
We support KnownBits for vectors, so we can enable these. https://godbolt.org/z/r9a9W4Gj1 Differential Revision: https://reviews.llvm.org/D135719
lldb-vscode is hard-coded to source .lldbinit file which causes some tests to fail on my machine. This patch adds a new option to control this: 1. vscode.py and lldb-vscode tests will not source .lldbinit by default 2. lldb-vscode will source .lldbinit in production if not specified otherwise Differential Revision: https://reviews.llvm.org/D135620
The Offloading toolchain currently has two methods for construction the requires actions. The "new" driver and the old `OffloadActionBuilder`. Using either one is mutually exclusive, so we should not initialize this when using the new driver. This was causing some error messages to be printed multiple times because we were checking them in both the old and the new driver. Reviewed By: tra Differential Revision: https://reviews.llvm.org/D135715
Codegen options are typically unused by modules. Reset some of them to increase sharing between TUs with different flags. Reviewed By: Bigcheese Differential Revision: https://reviews.llvm.org/D135720
The dependency scanner needs to report the module map file describing the module whose implementation is being compiled (see D134222). However, calling `Preprocessor::getCurrentModuleImplementation()` in the scanner might cause a diagnostic during module map parsing and emitting a diagnostic without being "in" a source file is illegal (e.g. in `TextDiagnosticPrinter`). This patch ensures the module map parse is triggered while the compiler is still "in" a source file, avoiding the failure case. Reviewed By: Bigcheese Differential Revision: https://reviews.llvm.org/D135637
This provides a workaround for a small difference in ld64 behavior where ld64 ignores invalid LC_LINKER_OPTIONS unless the link fails. Instead of fully adopting that behavior, this provides an escape hatch by allowing users to specify `--ignore-auto-link-option` passing the invalid library or framework name Fixes llvm#56939 Differential Revision: https://reviews.llvm.org/D135530
… Y)) (sra X, BW-1) is either 0 or -1. So the multiply is a conditional negate of Y. This pattern shows up when type legalizing wide multiplies involving a sign extended value. Fixes PR57549. Reviewed By: RKSimon Differential Revision: https://reviews.llvm.org/D133399
…tput. Reviewed By: aartbik, wrengr Differential Revision: https://reviews.llvm.org/D135480
…functions Reviewed By: aeubanks Differential Revision: https://reviews.llvm.org/D135524
This isn't bound to any instruction. From the section comment it was for single-width F-to-F conversions, but those don't exist.
…, BW-1), Y))" This reverts commit 0148df8. Getting a lit test failures on AMDGPU but I can't reproduce it so far. Reverting to investigate.
…ess of the policy operand. If the source is implicit_def, the register allocator won't have any constraint on what register it picks for the destination. This doesn't give the user much control of what register is being used. So in my mind that means the only reason to honor the policy operand is to control what policy is used in vsetvli to maybe avoid a vtype change. Given the other optimizations we do on the policy field, I don't think allowing the user this control is reliable. Therefore, I think we should use agnostic policies if the source is undef. This should give better performance on some CPUs for VP intrinsics where there is no merge operand and the backend adds IMPLICIT_DEF to the instruction. Differential Revision: https://reviews.llvm.org/D135396
…rizableOpInterfaceImpl.cpp (NFC)
The patch selects VSELECT/VP_MERGE_VL which uses fmadd/fnmsub as true operand and the adden of the fmadd/fnmsub as false operand. Reviewed By: craig.topper Differential Revision: https://reviews.llvm.org/D135330
Fix the issue: llvm#57684 Reviewed By: efriedma Differential Revision: https://reviews.llvm.org/D135512
We already do this for personality pointers referenced from compact unwind entries; this patch extends that behavior to personalities referenced via EH frames as well. This reduces the number of distinct personalities we need in the final binary, and helps us avoid hitting the "too many personalities" error. I renamed `UnwindInfoSection::prepareRelocations()` to simply `prepare` since we now do some non-reloc-specific stuff within. Fixes llvm#58277. Reviewed By: #lld-macho, oontvoo Differential Revision: https://reviews.llvm.org/D135728
…al of `_cmd` parameter. This fixes a bug from https://reviews.llvm.org/D131424 that removed the implicit `_cmd` parameter as an argument to `objc_direct` method implementations. In many cases the generated getter/setter will call `objc_getProperty` or `objc_setProperty`, both of which require the selector of the getter/setter; since `_cmd` didn't automatically have backing storage, attempting to load the address asserted. For direct property generated getters/setters, this now passes an undefined/uninitialized/poison value as the `_cmd` argument to `objc_getProperty`/`objc_setProperty`. Prior to removing the `_cmd` argument from the ABI of direct methods, it was left uninitialized/undefined; although references within hand-implemented methods would load the selector in the method prologue, generated getters/setters never did and just forwarded the undefined value that was passed as the argument. This change keeps the generated code mostly similar to before, passing an uninitialized/undefined/poison value; for setters, the value argument may be moved to another register. Added a test that triggers the assert prior to the implementation code. Differential Revision: https://reviews.llvm.org/D135091
COMPILER_RT_LIBCXX_PATH is required for msan unittests.
…eUsingInterface.cpp (NFC)
The specific case I hit this was when lowering an `async.execute` that's not inside a `func.func` op, e.g.: ``` llvm.func @foo() { %token = async.execute { async.yield } llvm.return } ``` Reviewed By: bondhugula Differential Revision: https://reviews.llvm.org/D135742
…NG_LIBCLANG_SOVERSION Instead of setting libclang.so's SOVERSION to CLANG_MAJOR_VERSION when CLANG_FORCE_MATCHING_LIBCLANG_SOVERSION is enabled, do not override it and let LLVM set the correct SOVERSION. This fixes libclang.so missing LLVM_VERSION_SUFFIX, and harmonizes the SOVERSION with other shared libraries. Differential Revision: https://reviews.llvm.org/D135701
Improve the logic in FindZstd to support finding both shared and static variants of the zstd library simultaneously. Otherwise, if the shared library is installed, zstd::libzstd_static is not declared at all and CMake fails if LLVM_USE_STATIC_ZSTD is used. Differential Revision: https://reviews.llvm.org/D135457
Split out a major peice of this method to make code more readable.
These are semantically two different stages, but were entwined in the old implementation. Now cost computation does not do legality checks, and they all are done beforehead.
The `-ivfsoverlay` flag was only being respected when the scanner was instructed to minimize the inputs. This patch respects that flag even in canonical preprocessing mode. Depends on D135414. Reviewed By: Bigcheese Differential Revision: https://reviews.llvm.org/D135416
…ferRewriting.cpp (NFC)
HIP is installed at /usr or /usr/local on Debin/Fedora,
and the version file is at {root}/share/hip/version.
Reviewed by: Artem Belevich
Differential Revision: https://reviews.llvm.org/D135796
The functionality is fine (we don't run the breakpoint command twice), but this test forgot to call `FileCheck` and isn't checking the same value isn't there twice..
…off support
Fixed error
```
Command Output (stderr):
--
fatal error: error in backend: Objective-C support is unimplemented for object file format
```
Source code in `clang/lib/CodeGen/CGObjCMac.cpp:5080`
```
case llvm::Triple::Wasm:
case llvm::Triple::GOFF:
case llvm::Triple::SPIRV:
case llvm::Triple::XCOFF:
case llvm::Triple::DXContainer:
llvm::report_fatal_error(
"Objective-C support is unimplemented for object file format");
}
```
Reviewed By: hubert.reinterpretcast
Differential Revision: https://reviews.llvm.org/D135848
cbuffer A {
float a;
float b;
}
will be translated to a global variable.
Something like
struct CB_Ty {
float a;
float b;
};
CB_Ty A;
And all use of a and b will be replaced with A.a and A.b.
Only support none-legacy cbuffer layout now.
CodeGen for Resource binding will be in separate patch.
In the separate patch, resource binding will map the resource information to the global variable.
Reviewed By: efriedma
Differential Revision: https://reviews.llvm.org/D130131
…arameters
The Clang Static Analyzer will crash on this code:
```lang=C++
struct Box {
int value;
};
template <Box V> int get() {
return V.value;
}
template int get<Box{-1}>();
```
https://godbolt.org/z/5Yb1sMMMb
The problem is that we don't account for encountering `TemplateParamObjectDecl`s
within the `DeclRefExpr` handler in the `ExprEngine`.
IMO we should create a new memregion for representing such template
param objects, to model their language semantics.
Such as:
- it should have global static storage
- for two identical values, their addresses should be identical as well
http://eel.is/c%2B%2Bdraft/temp.param#8
I was thinking of introducing a `TemplateParamObjectRegion` under `DeclRegion`
for this purpose. It could have `TemplateParamObjectDecl` as a field.
The `TemplateParamObjectDecl::getValue()` returns `APValue`, which might
represent multiple levels of structures, unions and other goodies -
making the transformation from `APValue` to `SVal` a bit complicated.
That being said, for now, I think having `Unknowns` for such cases is
definitely an improvement to crashing, hence I'm proposing this patch.
Reviewed By: xazax.hun
Differential Revision: https://reviews.llvm.org/D135763
Whenever a call to __chkstk was made, the frame lowering previously omitted the aligning (as NumBytes was reset to zero before doing alignment). This fixes llvm#56182. Differential Revision: https://reviews.llvm.org/D135687
… NFC. If the stack is realigned, we've emitted a frame pointer and already terminated the SEH prologue, making this dead code since a07787c. The immediate to this SEH opcode was entirely bogus - we don't know how many bytes the AND operation adjusts the SP, and by doing "NumBytes & andMaskEncoded" (where andMaskEncoded was the immediate bitpattern for the AND instruction), the immediate to the opcode was total gibberish. This hasn't had any practical effect, since the original stack pointer always was restored from the frame pointer afterwards anyway. Differential Revision: https://reviews.llvm.org/D135815
…AND. NFC. Differential Revision: https://reviews.llvm.org/D135817
…tching number of instructions This matches what was done for the ARM implementation (where getting the instruction sizes right is even more tricky, and hence needed tighter testing). This will allow catching any future cases where prologs and epilogs don't match the instructions within them. Differential Revision: https://reviews.llvm.org/D131394
Add FileCheck directives to existing tests in preparation for new tests. Reviewed By: arsenm Differential Revision: https://reviews.llvm.org/D135788
`getIteratorTypesArray` should be used instead. It's a better substitute for all the current usages of the interface. The current `ArrayAttr iterator_types()` has a few problems: * It creates an assumption operation has iterators types as an attribute, but it's not always the case. Sometime iterator types can be inferred from other attribute, or they're just static. * ArrayAttr is an obscure contained and required extracting values in the client code. * Makes it hard to migrate iterator types from strings to enums ([RFC](https://discourse.llvm.org/t/rfc-enumattr-for-iterator-types-in-linalg/64535/9)). Concrete ops, like `linalg.generic` will still have iterator types as an attribute if needed. As a side effect, this change helps a bit with migration to prefixed accessors. Differential Revision: https://reviews.llvm.org/D135765
The MemRef to LLVM conversion pass emits `llvm.alloca` operations to promote MemRef descriptors to the stack when lowering `memref.copy` operations for operands which do not have a contiguous layout in memory. The original stack position is never restored after the allocations, which creates an issue when the copy operation is embedded into a loop with a high trip count, ultimately resulting in a segmentation fault due to the stack growing too large.
Below is as a minimal example illustrating the issue:
```
module {
func.func @main() {
%arg0 = memref.alloc() : memref<32x64xi64>
%arg1 = memref.alloc() : memref<16x32xi64>
%lb = arith.constant 0 : index
%ub = arith.constant 100000 : index
%step = arith.constant 1 : index
%slice = memref.subview %arg0[16,32][16,32][1,1] :
memref<32x64xi64> to memref<16x32xi64, #map>
scf.for %i = %lb to %ub step %step {
memref.copy %slice, %arg1 :
memref<16x32xi64, #map> to memref<16x32xi64>
}
return
}
}
```
When running the code above, e.g., with mlir-cpu-runner, the execution crashes with a segmentation fault:
```
$ mlir-opt \
--convert-scf-to-cf \
--convert-memref-to-llvm \
--convert-func-to-llvm
--convert-cf-to-llvm \
--reconcile-unrealized-casts <file> | \
mlir-cpu-runner \
-e main -entry-point-result=void \
--shared-libs=$PWD/build/lib/libmlir_c_runner_utils.so
[...]
Segmentation fault
```
This patch causes the code lowering a `memref.copy` operation in the MemRefToLLVM pass to emit a pair of matching `llvm.intr.stacksave` and `llvm.intr.stackrestore` operations around the promotion of memory descriptors and the subsequent call to `memrefCopy` in order to restore the stack to its original position after the call.
Reviewed By: ftynse
Differential Revision: https://reviews.llvm.org/D135756
The code for inferring memory attributes on arguments claims that inalloca/preallocated arguments are always clobbered: https://github.com/llvm/llvm-project/blob/d71ad4108056d685f48407447095d8d92fd7685d/llvm/lib/Transforms/IPO/FunctionAttrs.cpp#L640-L642 However, we would still infer memory attributes for the whole function without taking this into account, so we could still end up inferring readnone for the function. This adds an argument clobber if there are any inalloca/preallocated arguments. Differential Revision: https://reviews.llvm.org/D135783
Conversion performed using the script at: https://gist.github.com/nikic/98357b71fd67756b0f064c9517b62a34
non-polymorphic derived-type can call type-bound procedure with passed-object. In that case, the derived-type is emboxed in order to be passed to the call. Until now the emboxing was done to a fir.box followed by a fir.convert. This patch update the createBox function so that we can directly embox to a fir.class and avoid the extra fir.convert. Reviewed By: PeteSteinfeld Differential Revision: https://reviews.llvm.org/D135790
MachineInstr's copy constructor works by calling the addOperand method to add each operand of the old MachineInstr to the new one, one by one. But addOperand deliberately avoids trying to replicate ties between operands, on the grounds that the tie refers to operands by index, and the indices aren't necessarily finalized yet. This led to a code generation fault when the machine pipeliner cloned an Arm conditional instruction, and lost the tie between the output register and the input value to be used when the condition failed to execute. Reviewed By: dmgreen Differential Revision: https://reviews.llvm.org/D135434
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.
See Commits and Changes for more details.
Created by
pull[bot]
Can you help keep this open source service alive? 💖 Please sponsor : )