| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
FunctionCoverageSummary::get() for instantiation""
This reverts commit 33d312b2d731507327252fd597bac1b738870330.
The original patch was correct, so we need to restore it in the
release branch.
|
|
The ARMConstantIsland pass will convert any t2B to tB if they are within
range after it has added or moved any constant pools. They don't need to
be deliberately converted beforehand, and it doesn't deal with needing
to convert tB to t2B very well.
|
|
Now that we are calling SimplifyInstructionsInBlock, make sure we update
Changed when it reports alterations.
|
|
Surprisingly, not all instructions are always simplified after unrolling
and before MVE gather/scatter lowering. Notably dead gather operations
can be left around which cause the gather/scatter lowering pass to crash
if there are multiple gathers, some of which are dead.
This patch ensures they are simplified before we modify anything, which
can change some of the existing tests, including making them no-longer
test what they originally tested. This uses a combination of disabling
the gather/scatter lowering pass and adjusting the test to keep them as
before.
Differential Revision: https://reviews.llvm.org/D103150
|
|
|
|
CGP can move instructions like a ptrtoint into a loop, but the
MVETailPredication when converting them will currently assume invariant
trip counts. This tries to ensure the operands are loop invariant, and
bails if not.
Differential Revision: https://reviews.llvm.org/D100550
|
|
This ensures that the operands of any gather/scatter instructions that
we attempt to push out of the loop are invariant, preventing invalid IR
from being generated.
|
|
In function ConvertVPTBlocks(), it is assumed that every instruction
within a vector-predicated block is predicated. This is false for debug
instructions, used by LLVM.
Because of this, an assertion failure is reached when an input contains
debug instructions inside VPT blocks. In non-assert builds, an out of
bounds memory access took place.
The present patch properly covers the case of debug instructions.
Reviewed By: dmgreen
Differential Revision: https://reviews.llvm.org/D99075
|
|
Debug info is currently preventing VPT block creation, leading to
different codegen. This patch attempts to skip any debug instructions
during vpt block creation, making sure they do not interfere.
Differential Revision: https://reviews.llvm.org/D103610
|
|
|
|
The LLVM C API is missing type attributes as is needed by attributes
such as sret and byval. This patch adds three missing wrapper
functions.
Bugzilla: https://bugs.llvm.org/show_bug.cgi?id=48249
https://reviews.llvm.org/D97763
(cherry picked from commit 528f6f7d617757addac9b51dd5bcc1ab1352e9be)
|
|
Do not defer to the base class when the register constraint is a
physical fpr. The base class will select SPILLTOVSRRC as the register
class and register allocation will fail on subtargets without VSX
registers.
Differential Revision: https://reviews.llvm.org/D91629
(cherry picked from commit 4e127bce2d1133ba95a551d69bd0e8fc3b4f9e71)
|
|
Differential Revision: https://reviews.llvm.org/D98195
(cherry picked from commit 4289a7f1d78972e9f1fa173c8ee0f6b8b45223d7)
|
|
DWARFAttribute
`AttributeSpec` does not contain values while `DWARFAttribute` already
does. Therefore one no longer needs to pass `uint64_t *OffsetPtr`.
Differential Revision: https://reviews.llvm.org/D98194
(cherry picked from commit ba8907bf6f2cf5ca2f6d92a6dfe7bc9cf74f003f)
|
|
This patch is to address https://bugs.llvm.org/show_bug.cgi?id=48857.
Previous attempts can be found in D104007 and D101980.
A lot of discussions can be found in those two patches.
To summarize the bug:
When Clang emits IR for coroutines, the first thing it does is to make a copy of every argument to the local stack, so that uses of the arguments in the function will all refer to the local copies instead of the arguments directly.
However, in some cases we find that arguments are still directly used:
When Clang emits IR for a function that has pass-by-value arguments, sometimes it emits an argument with byval attribute. A byval attribute is considered to be local to the function (just like alloca) and hence it can be easily determined that it does not alias other values. If in the IR there exists a memcpy from a byval argument to a local alloca, and then from that local alloca to another alloca, MemCpyOpt will optimize out the first memcpy because byval argument's content will not change. This causes issues because after a coroutine suspension, the byval argument may die outside of the function, and latter uses will lead to memory use-after-free.
This is only a problem for arguments with either byval attribute or noalias attribute, because only these two kinds are considered local. Arguments without these two attributes will be considered to alias coro_suspend and hence we won't have this problem. So we need to be able to deal with these two attributes in coroutines properly.
For noalias arguments, since coro_suspend may potentially change the value of any argument outside of the function, we simply shouldn't mark any argument in a coroutiune as noalias. This can be taken care of in CoroEarly pass.
For byval arguments, if such an argument needs to live across suspensions, we will have to copy their value content to the frame, not just the pointer.
Differential Revision: https://reviews.llvm.org/D104184
(cherry picked from commit 3522167efd80e2fef42a865cdf7481d60d062603)
|
|
EDX were flipped for the AMD case.
Follow up to D97504
Differential Revision: https://reviews.llvm.org/D98322
(cherry picked from commit 64d2c326b7f01942f0179fb797070e5cefbba303)
|
|
[llvm-exegesis] Disable the LBR check on AMD
https://bugs.llvm.org/show_bug.cgi?id=48918
The bug reported a hang (or very very slow runtime) on a Zen2. Unfortunately, we don't have the hardware right now to debug it and I was not able to reproduce the bug on a HSW.
Theory we've got is that the lbr-checking code could be confused on AMD.
Differential Revision: https://reviews.llvm.org/D97504
New change:
- Surround usages of x86 helper in llvm-exegesis/X86/Target.cpp with ifdef
- Fix bug which caused the caller of getVendorSignature to not have a copy of EAX that it expected.
(cherry picked from commit f8b01d54c31547f3ecb25fb8a1912183026bffa7)
|
|
constants
Fixes PR49932
Reviewed By: mehdi_amini
Differential Revision: https://reviews.llvm.org/D100322
(cherry picked from commit ad9ce8142dd5b90f725ad362feb054d52a35aa1f)
|
|
Fixes PR42961.
Reviewed By: rnk
Differential Revision: https://reviews.llvm.org/D97872
(cherry picked from commit c8227f06b3356cdc9cc757d8888dfb59a6d8ad89)
|
|
Before this patch, feature-test macros didn't take special availability
markup into account, which means that feature-test macros can sometimes
appear to "lie". For example, if you compile in C++20 mode and target
macOS 10.13, the __cpp_lib_filesystem feature-test macro will be provided
even though the <filesystem> declarations are marked as unavailable.
This patch fixes that.
rdar://68142369
Differential Revision: https://reviews.llvm.org/D94983
(cherry picked from commit 76fc35752d19ac605c1c1fd757af9c7c3bb4a906)
|
|
array types.
Refs: https://bugs.llvm.org/show_bug.cgi?id=32147
Differential Revision: https://reviews.llvm.org/D80882
(cherry picked from commit 097d77d611d1e1b3972be661fdc3caaa4d1824b4)
|
|
Summary:
When building with gcc on AIX, it seems that gcc does not like the
`always_inline` without the `inline` keyword.
So adding the inline keywords in for __open in ifstream and ofstream.
That will also make it consistent with __open in basic_filebuf
(it seems we added `inline` there before for gcc build as well).
Differential Revision: https://reviews.llvm.org/D99422
(cherry picked from commit 52e9d80d5db20f23979e409f958736d130387f9e)
|
|
The Linux kernel has removed the interface to cyclades from
the latest kernel headers[1] due to them being orphaned for the
past 13 years.
libsanitizer uses this header when compiling against glibc, but
glibcs itself doesn't seem to have any references to cyclades.
Further more it seems that the driver is broken in the kernel and
the firmware doesn't seem to be available anymore.
As such since this is breaking the build of libsanitizer (and so the
GCC bootstrap[2]) I propose to remove this.
[1] https://lkml.org/lkml/2021/3/2/153
[2] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100379
Reviewed By: eugenis
Differential Revision: https://reviews.llvm.org/D102059
(cherry picked from commit 68d5235cb58f988c71b403334cd9482d663841ab)
|
|
The new Docker images don't have gcc or g++, only the versioned equivalents.
|
|
When we removed the allocator<void> specialization, the triviality of
std::allocator<void> changed because the primary template had a
non-trivial default constructor and the specialization didn't
(so std::allocator<void> went from trivial to non-trivial).
This commit fixes that oversight by giving a trivial constructor to
the primary template when instantiated on cv-void.
This was reported in https://llvm.org/PR50299.
(cherry picked from commit 71e4d434dc83b02a853712a5cb026ee2fa9ba67f)
Differential Revision: https://reviews.llvm.org/D104486
|
|
As noted in https://bugs.llvm.org/show_bug.cgi?id=46666, the current behavior of assuming if-conversion safety if a loop is annotated parallel (`!llvm.loop.parallel_accesses`), is not expectable, the documentation for this behavior was since removed from the LangRef again, and can lead to invalid reads.
This was observed in POCL (https://github.com/pocl/pocl/issues/757) and would require similar workarounds in current work at hipSYCL.
The question remains why this was initially added and what the implications of removing this optimization would be.
Do we need an alternative mechanism to propagate the information about legality of if-conversion?
Or is the idea that conditional loads in `#pragma clang loop vectorize(assume_safety)` can be executed unmasked without additional checks flawed in general?
I think this implication is not part of what a user of that pragma (and corresponding metadata) would expect and thus dangerous.
Only two additional tests failed, which are adapted in this patch. Depending on the further direction force-ifcvt.ll should be removed or further adapted.
Reviewed By: jdoerfert
Differential Revision: https://reviews.llvm.org/D103907
(cherry picked from commit 4f01122c3f6c70beee8f736f196a09976602685f)
|
|
This fixes an issue introduced by https://reviews.llvm.org/D70662
Function-scope static initialization are guarded in C++, so we should probably
not use it because it introduces a dependency on __cxa_guard* symbols.
In the context of clang, libasan is linked statically, and it currently needs to
the odd situation where compiling C code with clang and asan requires -lstdc++
Differential Revision: https://reviews.llvm.org/D102475
(cherry picked from commit 414482751452e54710f16bae58458c66298aaf69)
|
|
As mentioned in https://gcc.gnu.org/PR100114 , glibc starting with the
https://sourceware.org/git/?p=glibc.git;a=commit;h=6c57d320484988e87e446e2e60ce42816bf51d53
change doesn't define SIGSTKSZ and MINSIGSTKSZ macros to constants, but to sysconf function call.
sanitizer_posix_libcdep.cpp has
static const uptr kAltStackSize = SIGSTKSZ * 4; // SIGSTKSZ is not enough.
which is generally fine, just means that when SIGSTKSZ is not a compile time constant will be initialized later.
The problem is that kAltStackSize is used in SetAlternateSignalStack which is called very early, from .preinit_array
initialization, i.e. far before file scope variables are constructed, which means it is not initialized and
mmapping 0 will fail:
==145==ERROR: AddressSanitizer failed to allocate 0x0 (0) bytes of SetAlternateSignalStack (error code: 22)
Here is one possible fix, another one could be to make kAltStackSize a preprocessor macro if _SG_SIGSTKSZ is defined
(but perhaps with having an automatic const variable initialized to it so that sysconf isn't at least called twice
during SetAlternateSignalStack.
Reviewed By: vitalybuka
Differential Revision: https://reviews.llvm.org/D100645
(cherry picked from commit 82150606fb11d28813ae6da1101f5bda638165fe)
|
|
(cherry picked from commit a83ef21ff82e4283044fd31470fc6c1bc4b99c51)
|
|
So don't define __tune__k8__ for these micro architecture.
SSE, SSE2 and SSE3 appear in https://www.amd.com/system/files/TechDocs/25112.PDF
but not SSE4.x.
Differential Revision: https://reviews.llvm.org/D104116
(cherry picked from commit 092c303955cd18be6c0b923b1c0a1b96e2c91893)
|
|
When a large "irregular" (e.g. i96) integer call argument is converted to
indirect, 64-bit parts are stored to the stack. The full stack space
(e.g. i128) was not allocated prior to this patch, but rather just the exact
space of the original type. This caused neighboring values on the stack to be
overwritten.
Thanks to Josh Stone for reporting this.
Review: Ulrich Weigand
Fixes https://bugs.llvm.org/show_bug.cgi?id=49322
Differential Revision: https://reviews.llvm.org/D97514
(cherry picked from commit 52bbbf4d4459239e0f461bc302ada89e2c5d07fc)
|
|
Ensures that `get_return_object`'s return type is the same as the return type for the function calling `co_return`. Otherwise, we try to construct an object, then free it, then return it.
Differential Revision: https://reviews.llvm.org/D103196
(cherry picked from commit 52123c96c016143ebfff6de76fe83cebd6c1d726)
|
|
GCC has been failing those tests, and we marked them as such in
a3ab5120fd572215afeac190757834a041dda73a on 'main'. Cherry-pick
only that part of the change into the LLVM 12 release so that we
can get the CI green again.
|
|
This allows us to turn -Wdeprecated-copy back on. We turned it off
in 3b71de41cc7c7 because Clang's implementation became more stringent
and started diagnosing the old code here.
Differential Revision: https://reviews.llvm.org/D101183
(cherry picked from commit 70d94c3f2cae71ade2ceacdceb3d2e9899d2289a)
|
|
This is a cherry-pick of 87784cc6fb3453a17e0e78 on 'main' for
backporting to LLVM 12.
Differential Revision: https://reviews.llvm.org/D104324
|
|
From https://llvm.org/docs/LangRef.html#asm-template-argument-modifiers:
I: Print the letter ‘i’ if the operand is an integer constant,
otherwise nothing. Used to print ‘addi’ vs ‘add’ instructions.
Differential Revision: https://reviews.llvm.org/D103968
(cherry picked from commit a9e4f91adf59bbc72541b96dd30245eaeeedf3ce)
|
|
UnwrappedLineParser
This commit removes the old way of handling Whitesmiths mode in favor of just setting the
levels during parsing and letting the formatter handle it from there. It requires a bit of
special-casing during the parsing, but ends up a bit cleaner than before. It also removes
some of switch/case unit tests that don't really make much sense when dealing with
Whitesmiths.
Differential Revision: https://reviews.llvm.org/D94500
(cherry picked from commit f7f9f94b2e2b4c714bac9036f6b73a3df42daaff)
|
|
Summary:
There was a typo in libomptarget that told users to use LIBOMPTARGET_DEBUG
instead of LIBOMPTARGET_INFO.
(cherry picked from commit 0af4e74aef2eaddc17e1e92eb6d1102cdb5f8ff4)
|
|
stack is realigned
When `-fstack-clash-protection` is enabled and stack has to be realigned, some parts of redzone is written prior the probe, so probe might overwrite content already written in redzone. To avoid it, we have to make sure the first probe is at full probe size or is the last probe so that we can skip redzone.
It also fixes violation of ABI under PPC where `r1` isn't updated atomically.
This fixes https://bugs.llvm.org/show_bug.cgi?id=49903.
Reviewed By: jsji
Differential Revision: https://reviews.llvm.org/D100290
(cherry picked from commit bf58600badb1138a501ad81b07298207a7a64b2a)
|
|
According to ELF V2 ABI, `0` should be the dwarf number of `r0`. Currently MMA's register also uses `0` as its dwarf number, this confuses `RegisterInfoEmitter` and generates wrong dwarf -> llvm mapping.
```
extern const MCRegisterInfo::DwarfLLVMRegPair PPCDwarfFlavour1Dwarf2L[] = {
{ 0U, PPC::VSRp31 },
```
This leads to wrong cfi output in https://reviews.llvm.org/D100290.
Reviewed By: jsji
Differential Revision: https://reviews.llvm.org/D103761
(cherry picked from commit c87c294397ea4c3dae31f5a7fd6e38602338fd57)
|
|
This is a fix for PR50481
Immediate values for AddrModeT2_i8s4 are already scaled in MCinst operand.
This patch changes the number of bits and scale factor to reflect that
state when checking stack offset status. AddrModeT2_i7s[2|4] also have
this particularity but since MVE instructions are not outlined, just move
these cases to the unhandled ones.
Differential Revision: https://reviews.llvm.org/D103167
(cherry picked from commit 6c78dbd4ca1f2c25cdc276d646c7920afe856ca3)
|
|
guarantee upper 32 bits are zero.
The freeze issue was reported here
https://llvm.discourse.group/t/bug-or-feature-freeze-instruction/3639
I don't have a test for AssertAlign. I just noticed it was missing
and assume it should be similar to the other two Asserts.
Reviewed By: RKSimon
Differential Revision: https://reviews.llvm.org/D104178
(cherry picked from commit c997867dc084a1bcf631816f964b3ff49a297ba3)
|
|
The current code accounts for two possible layouts, but there is at
least a third supported layout: clang-tools-extra may also be checked
out as clang/tools/extra with the releases, which was not yet handled.
Rather than treating that as a special case, use the location of
CompletionModel.cmake to handle all three cases. This should address the
problems that prompted D96787 and the problems that prompted the
proposed revert D100625.
Reviewed By: usaxena95
Differential Revision: https://reviews.llvm.org/D101851
(cherry picked from commit 7907c46fe6195728fafd843b8c0fb19a3e68e9ad)
|
|
llvm supports specifying a non-standard layout where each project lies in its
own place. Do not assume a fixed layout and use the appropriate cmake variable
instead.
Differential Revision: https://reviews.llvm.org/D96787
(cherry picked from commit f51ab1871655a9a96134c2636c37dcb5a6b01ac3)
|
|
If emit inlined region for master/critical directives, no need to clear
lambda/block context data, otherwise the variables cannot be found and
it causes a crash at compile time.
Differential Revision: https://reviews.llvm.org/D99280
(cherry picked from commit 7654bb6303d290b19cad29137be810e69a0bf917)
|
|
The current code can scan an unlimited number of instructions,
if the containing basic block is very large. The test case from
PR50155 contains a basic block with approximately 100k instructions.
To avoid this, limit the number of instructions we inspect. At
the same time, drop the limit on the number of basic blocks, as
this will be implicitly limited by the number of instructions as
well.
(cherry picked from commit 2cd78686055f1badb9aa55cb95e189548ffc82f0)
|
|
For a global weak symbol defined as below:
char g __attribute__((weak)) = 2;
LLVM generates an allocated global with WeakAnyLinkage,
for which BPF backend generates proper BTF info.
For the above example, if a modifier "const" is added like
const char g __attribute__((weak)) = 2;
LLVM generates an allocated global with WeakODRLinkage,
for which BPF backend didn't generate any BTF as it
didn't handle WeakODRLinkage.
This patch addes support for WeakODRLinkage and proper
BTF info can be generated for weak symbol defined with
"const" modifier.
Differential Revision: https://reviews.llvm.org/D100362
(cherry picked from commit 968292cb93198442138128d850fd54dc7edc0035)
|
|
This permits extern function (BTF_KIND_FUNC) be added
to BTF_KIND_DATASEC if a section name is specified.
For example,
-bash-4.4$ cat t.c
void foo(int) __attribute__((section(".kernel.funcs")));
int test(void) {
foo(5);
return 0;
}
The extern function foo (BTF_KIND_FUNC) will be put into
BTF_KIND_DATASEC with name ".kernel.funcs".
This will help to differentiate two kinds of external functions,
functions in kernel and functions defined in other bpf programs.
Differential Revision: https://reviews.llvm.org/D93563
(cherry picked from commit 886f9ff53155075bd5f1e994f17b85d1e1b7470c)
|
|
Some BPF programs compiled on s390 fail to load, because s390
arch-specific linux headers contain float and double types. At the
moment there is no BTF_KIND for floats and doubles, so the release
version of LLVM ends up emitting type id 0 for them, which the
in-kernel verifier does not accept.
Introduce support for such types to libbpf by representing them using
the new BTF_KIND_FLOAT.
Reviewed By: yonghong-song
Differential Revision: https://reviews.llvm.org/D83289
(cherry picked from commit a7137b238a07d9399d3ae96c0b461571bd5aa8b2)
|
|
As shown in:
https://llvm.org/PR50623
...and the similar tests here, we were not accounting for
store merging of different sizes that do not cover the
entire range of the wide value to be stored.
This is the easy fix: just make sure that all of the
original stores are the same size, so when we calculate
the wide width, it's a simple N * M check.
This still allows all of the motivating optimizations from:
D86420 / 54a5dd485c4d
D87112 / 7a06b166b1af
We could enhance this code to track individual bytes and
allow merging multiple sizes.
(cherry picked from commit dd763ac79196b3d3bc0370b9dbd35e0c083e52a4)
|
