Summary:
We have handle the InstAlias for OR instructions, but we handle it
agagin in PPCInstPrinter.cpp.
This patch is to Remove the redundant InstAlias for OR instruction.
Reviewed By: steven.zhang
Differential Revision: https://reviews.llvm.org/D80502
The previous implementation used "asm parser only" pseudo-instructions in their
output patterns. Those are not meant to emit code and will caused crashes when
built with -filetype=obj.
Differential Revision: https://reviews.llvm.org/D80151
The function emitRLDICWhenLoweringJumpTables in PPCMIPeephole.cpp
was supposed to convert a pair of RLDICL and RLDICR to a single RLDIC,
but it was leaving out the RLDICL instruction. This PR fixes the bug.
Differential Revision: https://reviews.llvm.org/D78063
Fix the incorrect PC Relative relocations for Big Endian for 34 bit offsets.
The offset should be zero for both BE and LE in this situation.
Differential Revision: https://reviews.llvm.org/D81033
Add support to lld to use Text Based API stubs for linking. This is
support is incomplete not filtering out platforms. It also does not
account for architecture specific API handling and potentially does not
correctly handle trees of re-exports with inlined libraries being
treated as direct children of the top level library.
Summary:
UnrankedMemRefType doesn't have a rank but previously this was just
checking for unranked tensor. Avoids failure later if one queries the shape
post checking if ranked.
Differential Revision: https://reviews.llvm.org/D81441
Summary:
This patch adds support of using the result of an expression as an
immediate value. For example,
0:
.skip 4
1:
mov x0, 1b - 0b
is assembled to
mov x0, #4
Currently it does not support expressions requiring relocation unless
explicitly specified. This fixes PR#45781.
Reviewers: peter.smith, ostannard, efriedma
Reviewed By: efriedma
Subscribers: nickdesaulniers, llozano, manojgupta, efriedma, ostannard, kristof.beyls, hiraditya, danielkiss, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D80028
These commits set up the skeleton for SPIR-V to LLVM dialect conversion.
I created SPIR-V to LLVM pass, registered it in Passes.td, InitAllPasses.h.
Added a pattern for `spv.BitwiseAndOp` and tests for it. Integer, float
and vector types are converted through LLVMTypeConverter.
Differential Revision: https://reviews.llvm.org/D81100
The !associated metadata may be attached to a global object declaration
with a single argument that references another global object. This
metadata prevents discarding of the global object in linker GC unless
the referenced object is also discarded.
Furthermore, when a function symbol is discarded by the linker, setting
up !associated metadata allows linker to discard counters, data and
values associated with that function symbol. This is not possible today
because there's metadata to guide the linker. This approach is also used
by other instrumentations like sanitizers.
Note that !associated metadata is only supported by ELF, it does not have
any effect on non-ELF targets.
Differential Revision: https://reviews.llvm.org/D76802
Slice::operator<() has a non-deterministic behavior. If we have
identical slices comparison will depend on the order or operands.
Normally that does not result in unstable compilation results
because the order in which slices are inserted into the vector
is deterministic and llvm::sort() normally behaves as a stable
sort, although that is not guaranteed.
However, there is test option -sroa-random-shuffle-slices which
is used to check exactly this aspect. The vector is first randomly
shuffled and then sorted. The same shuffling happens without this
option under expensive llvm checks.
I have managed to write a test which has hit this problem.
There are no fields in the Slice class to resolve the instability.
We only have offsets, IsSplittable and Use, but neither Use nor
User have anything suitable for predictable comparison.
I have switched to stable_sort which has to be sufficient and
removed that randon shuffle option.
Differential Revision: https://reviews.llvm.org/D81310
DiagnosticErrorTrap is usually inappropriate because it indicates
whether an error message was rendered in a given region (and is
therefore affected by -ferror-limit and by suppression of errors if we
see an invalid declaration).
hasErrorOccurred() is usually inappropriate because it indicates
whethere an "error:" message was displayed, regardless of whether the
message was a warning promoted to an error, and therefore depends on
things like -Werror that are usually irrelevant.
Where applicable, CodeSynthesisContexts are used to attach notes to
the first diagnostic produced in a region of code, isnstead of using an
error trap and then attaching a note to whichever diagnostic happened to
be produced last (or suppressing the note if the final diagnostic is a
disabled warning!).
This is mostly NFC.
Summary:
ROCm.h had been getting the declarations for various data structures
by being #included next to them, rather than #includeing them itself.
This change fixes that by explicitly including the appropriate headers.
Subscribers: cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D81432
Commit d77ae1552f ("[DebugInfo] Support to emit debugInfo
for extern variables") added support to emit debuginfo
for extern variables. Currently, only BPF target enables to
emit debuginfo for extern variables.
But if the extern variable has "void" type, the compilation will
fail.
-bash-4.4$ cat t.c
extern void bla;
void *test() {
void *x = &bla;
return x;
}
-bash-4.4$ clang -target bpf -g -O2 -S t.c
missing global variable type
!1 = distinct !DIGlobalVariable(name: "bla", scope: !2, file: !3, line: 1,
isLocal: false, isDefinition: false)
...
fatal error: error in backend: Broken module found, compilation aborted!
PLEASE submit a bug report to https://bugs.llvm.org/ and include the crash backtrace,
preprocessed source, and associated run script.
Stack dump:
...
The IR requires a DIGlobalVariable must have a valid type and the
"void" type does not generate any type, hence the above fatal error.
Note that if the extern variable is defined as "const void", the
compilation will succeed.
-bash-4.4$ cat t.c
extern const void bla;
const void *test() {
const void *x = &bla;
return x;
}
-bash-4.4$ clang -target bpf -g -O2 -S t.c
-bash-4.4$ cat t.ll
...
!1 = distinct !DIGlobalVariable(name: "bla", scope: !2, file: !3, line: 1,
type: !6, isLocal: false, isDefinition: false)
!6 = !DIDerivedType(tag: DW_TAG_const_type, baseType: null)
...
Since currently, "const void extern_var" is supported by the
debug info, it is natural that "void extern_var" should also
be supported. This patch disabled assertion of "void extern_var"
in IR verifier and add proper guarding when emiting potential
null debug info type to dwarf types.
Differential Revision: https://reviews.llvm.org/D81131
The !associated metadata may be attached to a global object declaration
with a single argument that references another global object. This
metadata prevents discarding of the global object in linker GC unless
the referenced object is also discarded.
Furthermore, when a function symbol is discarded by the linker, setting
up !associated metadata allows linker to discard counters, data and
values associated with that function symbol. This is not possible today
because there's metadata to guide the linker. This approach is also used
by other instrumentations like sanitizers.
Note that !associated metadata is only supported by ELF, it does not have
any effect on non-ELF targets.
Differential Revision: https://reviews.llvm.org/D76802
Summary:
It is traditionally potentially very inefficient to not preallocate the memory,
but rely on reallocation every time you push something into vector.
For example, looking at unity build of RawSpeed
(`-O3 -g0 -emit-llvm -Xclang -disable-llvm-optzns`),
the memory story is as follows:
```
total runtime: 11.34s.
calls to allocation functions: 2694053 (237612/s)
temporary memory allocations: 645188 (56904/s)
peak heap memory consumption: 231.36MB
peak RSS (including heaptrack overhead): 397.39MB
```
Looking at details, `FoldingSetNodeID::AddString()` is noteworthy, frequently called and is allocation-heavy.
But it is quite obvious how many times we will push into `Bits` - we will push `String.size()` itself,
and then we will push once per every 4 bytes of `String` (padding last block).
And if we preallocate, we get:
```
total runtime: 11.20s.
calls to allocation functions: 2594704 (231669/s)
temporary memory allocations: 560004 (50000/s)
peak heap memory consumption: 231.36MB
peak RSS (including heaptrack overhead): 398.06MB
```
Which is a measurable win:
```
total runtime: -0.14s. # -1.23 %
calls to allocation functions: -99349 (719920/s) # -3.69 %
temporary memory allocations: -85184 (617275/s) # -13.2 % (!)
peak heap memory consumption: 0B
peak RSS (including heaptrack overhead): 0B
total memory leaked: 0B
```
Reviewers: efriedma, nikic, bkramer
Reviewed By: bkramer
Subscribers: hiraditya, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D81342
Reliably mark the loop variable declaration in a range for as having an
invalid initializer if anything goes wrong building the initializer. We
previously based this determination on whether an error was emitted,
which is not a reliable signal due to error suppression (during error
recovery etc).
Also, properly mark the variable as having initializer errors rather
than simply marking it invalid. This is necessary to mark any structured
bindings as invalid too.
This generalizes the previous fix in
936ec89e91.
If there are more than 65534 relocation entries in a single section,
we should generate an overflow section.
Since we don't support overflow section for now, we should generate
an error.
Differential revision: https://reviews.llvm.org/D81104
Summary: Apply workaround done in D81179 only for GCC < 8. As @klausler mentioned in D81179 we want to avoid additional checks for other compilers that do not need them.
Reviewers: DavidTruby, klausler, jdoerfert, sscalpone
Reviewed By: klausler, sscalpone
Subscribers: llvm-commits, tskeith, isuruf, klausler
Tags: #flang, #llvm
Differential Revision: https://reviews.llvm.org/D81208
This moves the SuffixTree test used in the Machine Outliner and moves it into Support for use in other outliners elsewhere in the compilation pipeline.
Differential Revision: https://reviews.llvm.org/D80586
This flag suppresses TSan FPs on Darwin. I removed this flag
prematurely and have been dealing with the fallout ever since.
This commit puts back the flag, reverting 7d1085cb [1].
[1] https://reviews.llvm.org/D55075
Summary:
Add -ftrivial-auto-var-init-stop-after= to limit the number of times
stack variables are initialized when -ftrivial-auto-var-init= is used to
initialize stack variables to zero or a pattern. This flag can be used
to bisect uninitialized uses of a stack variable exposed by automatic
variable initialization, such as http://crrev.com/c/2020401.
Reviewers: jfb, vitalybuka, kcc, glider, rsmith, rjmccall, pcc, eugenis, vlad.tsyrklevich
Reviewed By: jfb
Subscribers: phosek, hubert.reinterpretcast, srhines, MaskRay, george.burgess.iv, dexonsmith, inglorion, gbiv, llozano, manojgupta, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D77168
Currently aarch64-ldst-opt will incorrectly rename registers with
multiple disjunct subregisters (e.g. result of LD3). This patch updates
the canRenameUpToDef to bail out if it encounters such a register class
that contains the register to rename.
Fixes PR46105.
Reviewers: efriedma, dmgreen, paquette, t.p.northover
Reviewed By: efriedma
Differential Revision: https://reviews.llvm.org/D81108
Summary:
This fixes pr33372.cpp under the new pass manager.
ASan adds padding to globals. For example, it will change a {i32, i32, i32} to a {{i32, i32, i32}, [52 x i8]}. However, when loading from the {i32, i32, i32}, InstCombine may (after various optimizations) end up loading 16 bytes instead of 12, likely because it thinks the [52 x i8] padding is ok to load from. But ASan checks that padding should not be loaded from.
Ultimately this is an issue of *San passes wanting to be run after all optimizations. This change moves the module passes right next to the corresponding function passes.
Also remove comment that's no longer relevant, this is the last ASan/MSan/TSan failure under the NPM (hopefully...).
As mentioned in https://reviews.llvm.org/rG1285e8bcac2c54ddd924ffb813b2b187467ac2a6, NPM doesn't support LTO + sanitizers, so modified some tests that test for that.
Reviewers: leonardchan, vitalybuka
Subscribers: cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D81323
LowerSELECT sees the CMP with 0 and wants to use a trick with SUB
and SBB. But we can use the flags from the BSF/TZCNT.
Fixes PR46203.
Differential Revision: https://reviews.llvm.org/D81312
- Now all SalvageDebugInfo() calls will mark undef if the salvage
attempt fails.
Reviewed by: vsk, Orlando
Differential Revision: https://reviews.llvm.org/D78369
Use the default target triple configured by the user to determine the
default architecture for `ld64.lld`. Stash the architecture in the
configuration as when linking against TBDs, we will need to filter out
the symbols based upon the architecture. Treat the Haswell slice as it
is equivalent to `x86_64` but with the extra Haswell extensions (e.g.
AVX2, FMA3, BMI1, etc). This will make it easier to add new
architectures in the future.
This change also changes the failure mode where an invalid `-arch`
parameter will result in the linker exiting without further processing.
This patch adds a test to check that we do not use an undef renamable
register for renaming the other operand in a LDP instruction, as
suggested in D81108.
We sometimes have functions with large numbers of sibling basic
blocks (usually with an error path exit from each one). This was
triggering the qudratic behavior in this function - after visiting
each child llvm would re-scan the parent from the beginning again. We
modify the work stack to record the next index to be worked on
alongside the pointer. This avoids the need to linearly search for
the next unfinished child.
Differential Revision: https://reviews.llvm.org/D80029
