This intention of this code turns out to be superfluous as we can handle this with shuffle combining, and it has a critical flaw in that it doesn't check for dependencies.
Fixes PR51974
(cherry picked from commit 468ff703e1)
Clang 13 has a -fsanitize-coverage -fno-semantic-interposition bug (D117190)
which may lead to
`relocation R_X86_64_PC32 cannot be used against symbol` linker error
in -DLLVM_USE_SANITIZE_COVERAGE=ON build when a shared object is built (e.g.
-DLLVM_BUILD_LLVM_DYLIB=on).
For simplicity, just disallow Clang 13 entirely.
Note: GCC -fPIC performance benefits from -fno-semantic-interposition
dramatically. Clang benefits little. Using this option is more for a dogfood
purpose to test correctness of this option, because in the wild some important
packages like CPython uses this option.
Differential Revision: https://reviews.llvm.org/D117183
(cherry picked from commit 1661c8cfcd)
Some of the Arm complex pattern functions call canExtractShiftFromMul,
which can modify the DAG in-place. For this to be valid and handled
successfully we need to define ComplexPatternFuncMutatesDAG.
Differential Revision: https://reviews.llvm.org/D107476
(cherry picked from commit 77e8f4eeee)
This fixes bug52896.
Simply, some symmetric transfer optimization chances get invalided due
to we delete some inlined optimization passes in 822b92a. This would
cause stack-overflow in some situations which should be avoided by the
design of coroutine. This patch tries to fix this by transforming the
constant CmpInst instruction which was done in the deleted passes.
Reviewed By: rjmccall, junparser
Differential Revision: https://reviews.llvm.org/D116327
(cherry picked from commit 403772ff1c)
This option is for groups who need time to accomodate the ld.lld -z
start-stop-gc default.
This is a modified version of https://reviews.llvm.org/D114186 that
enables this option by default.
llvm.is.constant* intrinsics are evaluated to 0 or 1 integral values.
A common use case for llvm.is.constant comes from the higher level
__builtin_constant_p. A common usage pattern of __builtin_constant_p in
the Linux kernel is:
void foo (int bar) {
if (__builtin_constant_p(bar)) {
// lots of code that will fold away to a constant.
} else {
// a little bit of code, usually a libcall.
}
}
A minor issue in InlineCost calculations is when `bar` is _not_ Constant
and still will not be after inlining, we don't discount the true branch
and the inline cost of `foo` ends up being the cost of both branches
together, rather than just the false branch.
This leads to code like the above where inlining will not help prove bar
Constant, but it still would be beneficial to inline foo, because the
"true" branch is irrelevant from a cost perspective.
For example, IPSCCP can sink a passed constant argument to foo:
const int x = 42;
void bar (void) { foo(x); }
This improves our inlining decisions, and fixes a few head scratching
cases were the disassembly shows a relatively small `foo` not inlined
into a lone caller.
We could further improve this modeling by tracking whether the argument
to llvm.is.constant* is a parameter of the function, and if inlining
would allow that parameter to become Constant. This idea is noted in a
FIXME comment.
Link: https://github.com/ClangBuiltLinux/linux/issues/1302
Reviewed By: kazu
Differential Revision: https://reviews.llvm.org/D111272
(cherry picked from commit 9697f93587)
The interface for these instructions changed with support for mandatory tail
calls, and now -1 indicates the CalleePopAmount argument is not valid.
Unfortunately I didn't realise FastISel or GISel did calls at the time so
didn't update them.
(cherry picked from commit 0b5b35fdbd)
This change fixes a compiler crash that was introduced in https://reviews.llvm.org/D103611: `Sema::BuildVAArgExpr` attempted to retrieve a corresponding signed type for `bool` by calling `ASTContext::getCorrespondingSignedType`.
rdar://86580370
Reviewed By: aaron.ballman
Differential Revision: https://reviews.llvm.org/D116272
(cherry picked from commit c033f0d9b1)
If the parameter had been annotated as nonnull because of the null
check, we want to remove the attribute, since it may no longer apply and
could result in miscompiles if left. Similarly, we also want to remove
undef-implying attributes, since they may not apply anymore either.
Fixes PR52110.
Reviewed By: nikic
Differential Revision: https://reviews.llvm.org/D111515
(cherry picked from commit 6404f4b5af)
We have a large compile showing occasional non-deterministic behavior
that is due to DIArgList not being properly uniqued in some cases. I
tracked this down to handleChangedOperands, for which there is a custom
implementation for DIArgList, that does not take care of re-uniquing
after updating the DIArgList Args, unlike the default version of
handleChangedOperands for MDNode.
Since the Args in the DIArgList form the key for the store, this seems
to be occasionally breaking the lookup in that DenseSet. Specifically,
when invoking DIArgList::get() from replaceVariableLocationOp, very
occasionally it returns a new DIArgList object, when one already exists
having the same exact Args pointers. This in turn causes a subsequent
call to Instruction::isIdenticalToWhenDefined on those two otherwise
identical DIArgList objects during a later pass to return false, leading
to different IR in those rare cases.
I modified DIArgList::handleChangedOperands to perform similar
re-uniquing as the MDNode version used by other metadata node types.
This also necessitated a change to the context destructor, since in some
cases we end up with DIArgList as distinct nodes: DIArgList is the only
metadata node type to have a custom dropAllReferences, so we need to
invoke that version on DIArgList in the DistinctMDNodes store to clean
it up properly.
Differential Revision: https://reviews.llvm.org/D108968
(cherry picked from commit badcd58589)
Changes from commit 1db137b185
added iteration over hash map that can result in non-deterministic
order. Fix that by using a SmallMapVector to preserve the order.
Differential Revision: https://reviews.llvm.org/D113468
(cherry picked from commit 3c47c5ca13)
Fix handling of alloc-like instructions in isGuaranteedLoopInvariant(). It was not valid when the 'KillingDef' was outside of the loop, while the 'CurrentDef' was inside the loop. In that case, the 'KillingDef' only overwrites the definition from the last iteration of the loop, and not the ones of all iterations. Therefor it does not make the 'CurrentDef' to be dead, and must not remove it.
Fixing issue : https://github.com/llvm/llvm-project/issues/52774
Reviewed by: Florian Hahn
Differential revision: https://reviews.llvm.org/D115965
(cherry picked from commit 90d1786ba0)
Pre-commiting the test case before the bug fix.
Reviewed by: Florian Hahn
Differential revision: https://reviews.llvm.org/D115965
(cherry picked from commit df590567aa)
MachineOutliner may outline a "patchable-function-entry" function whose body has
a TargetOpcode::PATCHABLE_FUNCTION_ENTER MachineInstr. This is incorrect because
the special code sequence must stay unchanged to be used at run-time.
Avoid outlining PATCHABLE_FUNCTION_ENTER. While here, avoid outlining FENTRY_CALL too
(which doesn't reproduce currently) to allow phase ordering flexibility.
Fixes#52635
Reviewed By: paquette
Differential Revision: https://reviews.llvm.org/D115614
(cherry picked from commit a6a07a514b)
As reported in https://bugs.freebsd.org/260078, the gnutls Makefiles
pass -Wa,-march=all to compile a number of assembly files. Clang does
not support this -march value, but because of a mistake in handling
the arguments, an unitialized Arg pointer is dereferenced, which can
cause a segfault.
Work around this by adding a check if the local WaMArch variable is
initialized, and if so, using its value in the diagnostic message.
Reviewed By: tschuett
Differential Revision: https://reviews.llvm.org/D114677
(cherry picked from commit df08b2fe8b)
As mentioned in D106585, this causes non-determinism, which can also be
shown by this test case being flaky without this patch.
We were using the APSInt's bit width for hashing, but not for checking
for equality. APInt::isSameValue() does not check bit width.
Reviewed By: rnk
Differential Revision: https://reviews.llvm.org/D115054
(cherry picked from commit 93a20ecee4)
Since XLC only ever shipped on PowerPC AIX and Linux, it is not reasonable to
provide the compatibility macros on any target other than those two. This patch
restricts those macros to AIX/Linux.
Differential revision: https://reviews.llvm.org/D110213
(cherry picked from commit c9539f957f)
Commit 8fa3e8fa14 added an implicit REP prefix to all VIA PadLock
instructions, but GNU as doesn't add one to xstore, only all the others.
This resulted in a kernel panic regression in FreeBSD upon updating to
LLVM 11 (https://bugs.freebsd.org/259218) which includes the commit in
question. This partially reverts that commit.
Reviewed By: craig.topper
Differential Revision: https://reviews.llvm.org/D112355
(cherry picked from commit 2d8c18fbbd)
We currently only test the encoding of xstore but none of the other
instructions, which should all have their implicit REP prefix be
verified as working.
Reviewed By: craig.topper
Differential Revision: https://reviews.llvm.org/D112354
(cherry picked from commit b432583d28)
Add following interceptors on Linux: stat, lstat, fstat, fstatat.
This fixes use-of-uninitialized value on platforms with GLIBC 2.33+.
In particular: Arch Linux, Ubuntu hirsute/impish.
The tests should have also been failing during the release on the mentioned platforms, but I cannot find any related discussion.
Most likely, the regression was introduced by glibc commit [[ 8ed005daf0 | 8ed005daf0ab03e14250032 ]]:
all stat-family functions are now exported as shared functions.
Before, some of them (namely stat, lstat, fstat, fstatat) were provided as a part of libc_noshared.a and called their __xstat dopplegangers. This is still true for Debian Sid and earlier Ubuntu's. stat interceptors may be safely provided for them, no problem with that.
Closes https://github.com/google/sanitizers/issues/1452.
See also https://jira.mariadb.org/browse/MDEV-24841
Reviewed By: eugenis
Differential Revision: https://reviews.llvm.org/D111984
(cherry picked from commit 4e1a6c0705)
Before this change, AAResults::getModRefInfo() was missing a case for
callbr instructions (asm goto), which may read/write memory. In PR52735,
this led to a miscompile where a load was incorrect eliminated.
Add this missing case, as well as an assert verifying that all
memory-accessing instructions are handled properly.
Fixes#52735.
Differential Revision: https://reviews.llvm.org/D115992
(cherry picked from commit 9927a06f74)
GCC's powerpc32 port predefines `PPC` as a macro in GNU C++ mode in some configurations (Linux,
FreeBSD, and some others. See `builtin_define_std ("PPC"); ` in gcc/config/rs6000).
```
% powerpc-linux-gnu-g++ -E -dM -xc++ /dev/null -o - | grep -w PPC
#define PPC 1
```
Fixes https://bugs.gentoo.org/829599
Reviewed By: thesamesam
Differential Revision: https://reviews.llvm.org/D116017
(cherry picked from commit bee5bc9075)
Support for builtin setjmp/longjmp was removed by https://reviews.llvm.org/D51487. An
error should be created when compiling C code using __builtin_setjmp or __builtin_longjmp.
Reviewed By: dcederman
Differential Revision: https://reviews.llvm.org/D108901
(cherry picked from commit eeb4266f81)
blockaddresses do not participate in the call graph since the only
instructions that use them must all return to someplace within the
current function. And passes cannot retrieve a function address from a
blockaddress.
This was suggested by efriedma in D58260.
Fixes PR50881.
Reviewed By: nickdesaulniers
Differential Revision: https://reviews.llvm.org/D112178
(cherry picked from commit 029f1a5344)
Increase kDlsymAllocPoolSize on the release branch as discussed on bug
51620, as an alternative to backporting
cb0e14ce6d and its dependencies.
The minimum size is 8192, as needed for the following test to pass:
AddressSanitizer-i386-linux :: TestCases/Linux/long-object-path.cpp
Fixes#51620
This patch fixes the relative table converter pass for the lookup table
accesses that are resulted in an instruction sequence, where gep is not
immediately followed by a load, such as gep being hoisted outside the loop
or another instruction is inserted in between them. The fix inserts the
call to load.relative.instrinsic in the original place of load instead of gep.
Issue is reported by FreeBSD via https://bugs.freebsd.org/259921.
Differential Revision: https://reviews.llvm.org/D115571
(cherry picked from commit e5a8af7a90)
The Power ISA defined l[bhwdq]arx as both base and
extended mnemonics. The base mnemonic takes the EH
bit as an operand and the extended mnemonic omits
it, making it implicitly zero. The existing
implementation only handles the base mnemonic when
EH is 1 and internally produces a different
instruction. There are historical reasons for this.
This patch simply removes the limitation introduced
by this implementation that disallows the base
mnemonic with EH = 0 in the ASM parser.
This resolves an issue that prevented some files
in the Linux kernel from being built with
-fintegrated-as.
Also fix a crash if the value is not an integer immediate.
(cherry picked from commit d6c0ef7887)
PLT usage needs the first 12 bytes of the .got section. We need to keep .got and
DT_GOT_PPC even if .got/_GLOBAL_OFFSET_TABLE_ are not referenced (large PIC code
may only reference .got2), which is the case in OpenBSD's ld.so, leading
to a misleading error, "unsupported insecure BSS PLT object".
Fix this by adding R_PPC32_PLTREL to the list of hasGotOffRel.
Reviewed By: MaskRay
Differential Revision: https://reviews.llvm.org/D114982
(cherry picked from commit 885fb9a257)
A series of unary operators and casts may obscure the variable we're
trying to analyze. Ignore them for the uninitialized value analysis.
Other checks determine if the unary operators result in a valid l-value.
Link: https://github.com/ClangBuiltLinux/linux/issues/1521
Reviewed By: nickdesaulniers
Differential Revision: https://reviews.llvm.org/D114848
(cherry picked from commit c4582a689c)
Follow up to D92052 and D94072, exposed due to D107707
Many assemblers to permit that only the first .section contains all
the attributes like '.lds_bss,"w",@nobits' and later section only
use the name ('.lds_bss') inheriting those attributes from the first
section. I turned out that the case that Type changed was missed
when implementing it - and D107707 make it much more likely to hit
that issue. That's fixed by this commit.
Reviewed By: MaskRay
Differential Revision: https://reviews.llvm.org/D114717
(cherry picked from commit c01c62c76c)
MIPS .debug_* sections should have SHT_MIPS_DWARF section type to
distinguish among sections contain DWARF and ECOFF debug formats, but in
assembly files these sections have SHT_PROGBITS (@progbits) type. Now
assembler shows 'changed section type for ...' error when parsing
`.section .debug_*,"",@progbits` directive for MIPS targets.
The same problem exists for x86-64 target and this patch extends
workaround implemented in D76151. The patch adds one more case
when assembler ignores section types mismatch after `SwitchSection()`
call.
Differential Revision: https://reviews.llvm.org/D107707
(cherry picked from commit 990e8025b5)
Make users aware what to do with ld.lld 13.0.0 / GNU ld<2015-10 --gc-sections
behavior.
Differential Revision: https://reviews.llvm.org/D114830
(cherry picked from commit 353fe72ca3)
As explained in https://stackoverflow.com/a/70339311/627587, the fact
that shrink_to_fit wasn't defined as inline lead to issues when explicitly
instantiating basic_string. While explicit instantiations are always
somewhat brittle, this one was clearly a bug on our end.
Differential Revision: https://reviews.llvm.org/D115656
(cherry picked from commit bf39e7dc6c)
This fixes an issue introduced in D101996.
A weak reference in a shared library could be incorrectly reported if
there is another library that has a strong reference to the same symbol.
Differential Revision: https://reviews.llvm.org/D115041
(cherry picked from commit ce25eb12dd)
The changes in D80163 defered the assignment of MachineMemOperand (MMO)
until the X86ExpandPseudo pass. This will result in crash due to prolog
insert point been sunk across the pseudo instruction VASTART_SAVE_XMM_REGS.
Moving the assignment to the creation of the node can avoid the problem.
Reviewed By: rnk
Differential Revision: https://reviews.llvm.org/D112859
