| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
another node
SelectionDAG::transferDbgValues() can 'reattach' SDDbgValue from one to
another node, but doesn't change its source order. If the destination node has
the order greater than the SDDbgValue, there are two possible issues
revealed later:
* If debug info is attached to an instruction that is the first definition
of a register, this ends up with a def-after-use and the debug info
gets 'undef' later.
* If MIR has another definition of a register above the debug info,
the debug info may represent a source variable incorrectly because
it appears (significantly) before an instruction corresponded
to this debug info.
So, the patch changes the order of an SDDbgValue when it is moved
to a node with greater order.
Reviewers: dblaikie, jmorse, aprantl
Reviewed By: aprantl
Subscribers: aprantl, hiraditya, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D71175
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Linux powerpc discards `*(.gnu.version*)` (arch/powerpc/kernel/vmlinux.lds.S)
to suppress --orphan-handling=warn warnings in the -pie output `.tmp_vmlinux1`
The support is simple. Just add isLive() to:
1) Fix an assertion in SectionBase::getPartition() called by VersionTableSection::isNeeded().
2) Suppress DT_VERSYM, DT_VERDEF, DT_VERNEED and DT_VERNEEDNUM, if the relevant section is discarded.
Reviewed By: grimar
Differential Revision: https://reviews.llvm.org/D71819
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: Calling `changeToUnreachable` in `manifest` from different places might cause really unpredictable problems. As other deleting functions are doing, we need to change these instructions after all `manifest`.
Reviewers: jdoerfert, sstefan1
Reviewed By: jdoerfert
Subscribers: hiraditya, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D71910
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previous btf field relocation is always at assignment like
r1 = 4
which is converted from an ld_imm64 instruction.
This patch did an optimization such that relocation
instruction might be load/store/shift. Specically, the
following insns may also have relocation, except BPF_MOV:
LDB, LDH, LDW, LDD, STB, STH, STW, STD,
LDB32, LDH32, LDW32, STB32, STH32, STW32,
SLL, SRL, SRA
To accomplish this, a few BPF target specific
codegen only instructions are invented. They
are generated at backend BPF SimplifyPatchable phase,
which is at early llc phase when SSA form is available.
The new codegen only instructions will be converted to
real proper instructions at the codegen and BTF emission stage.
Note that, as revealed by a few tests, this optimization might
be actual generating more relocations:
Scenario 1:
if (...) {
... __builtin_preserve_field_info(arg->b2, 0) ...
} else {
... __builtin_preserve_field_info(arg->b2, 0) ...
}
Compiler could do CSE to only have one relocation. But if both
of the above is translated into codegen internal instructions,
the compiler will not be able to do that.
Scenario 2:
offset = ... __builtin_preserve_field_info(arg->b2, 0) ...
...
... offset ...
... offset ...
... offset ...
For whatever reason, the compiler might be temporarily do copy
propagation of the righthand of "offset" assignment like
... __builtin_preserve_field_info(arg->b2, 0) ...
... __builtin_preserve_field_info(arg->b2, 0) ...
and CSE will be able to deduplicate later.
But if these intrinsics are converted to BPF pseudo instructions,
they will not be able to get deduplicated.
I do not expect we have big instruction count difference.
It may actually reduce instruction count since now relocation
is in deeper insn dependency chain.
For example, for test offset-reloc-fieldinfo-2.ll, this patch
generates 7 instead of 6 relocations for non-alu32 mode, but it
actually reduced instruction count from 29 to 26.
Differential Revision: https://reviews.llvm.org/D71790
|
|
|
|
|
|
|
|
|
|
|
|
| |
This removes the OpenMPProcBindClauseKind enum in favor of
llvm::omp::ProcBindKind which lives in OpenMPConstants.h and was
introduced in D70109.
No change in behavior is expected.
Reviewed By: JonChesterfield
Differential Revision: https://reviews.llvm.org/D70289
|
|
|
|
| |
the AVX512DQ+AVX512VL code is very similar in both. NFC
|
|
|
|
|
|
|
| |
strict_sint_to_fp/strict_uint_to_fp for avx512dq+avx512vl targets.
With avx512dq+avx512vl we have instruction that implements this and
places zeroes in the upper 64-bits of the destination xmm register.
|
| |
|
|
|
|
| |
int<->fp tests.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This reverts part of commit 240aff80e0e59b79779d046b3275904fc0750d59.
It reverts cc802ea67beb66d2f8a935e647c3aedcf7848211.
We currently run LLVM tests in environments where python3 exists on
PATH, but it is broken. I don't think PATH discovery is a strong enough
signal that a working Python 3 installation exists.
If this will be the way forward, IMO we should follow the direction of
debug-info-tests, and use CMake's PYTHON_EXECUTABLE, which in the near
future will be a known-to-work Python 3 executable. If it's not Python
3, then we don't have to run this test.
|
|
|
|
|
|
|
|
|
|
| |
Reviewers: ldionne, jroelofs, EricWF
Subscribers: christof, dexonsmith, libcxx-commits
Tags: #libc
Differential Revision: https://reviews.llvm.org/D71890
|
|
|
|
|
| |
GCC produces incorrect .debug_macro section when "-include" option is used:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93075.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The enumeration EntryType is used as a bit field of DebugMacroEntry:
```
EntryType m_type : 3
```
Since underlying type of enumeration is implementation-dependent, a signed integer is
converted to the 3-bit value by some compilers (MSVC).
That's why a DebugMacroEntry instance that was created with EntryType value > 3 (END_FILE or INDIRECT)
contains incorrect negative value in its m_type data-member.
|
| |
|
|
|
|
| |
Required to make the category manually disableable.
|
| |
|
|
|
|
| |
If a remote target is not connected, SBPlatform's GetTriple function returns None.
|
| |
|
|
|
|
|
|
|
| |
This code actually needs a ClangASTContext but instead takes a
clang::ASTContext and then retrieves the original ClangASTContext
via the global map of ClangASTContexts. Let's change it so
that it takes a ClangASTContext which is simpler and faster.
|
|
|
|
|
|
|
|
|
|
| |
Building the sanitizers for watchOS currently fails with
sanitizer_common_interceptors.inc:9656:8: error: thread-local storage is not supported for the current target
static THREADLOCAL SIZE_T qsort_size;
I've also speculatively disabled QSORT interception for tvOS to unblock
failing builds. I'll ask someone with more sanitizer knowledge to check
after the holidays.
|
|
|
|
|
|
|
| |
GetASTContext is really expensive to call as it makes use of the global
mapping from ASTContext to ClangASTContext. This replaces all calls where
we already have the ClangASTContext around and don't need to call
GetASTContext again.
|
|
|
|
| |
This is a follow up commit to address post-commit comment in D70527.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
is not.
%1:g8rc = RLWINM8 %0:g8rc, 0, 16, 9
%2:g8rc = RLWINM8 killed %1:g8rc, 0, 0, 31
->
%2:g8rc = RLWINM8 %0:g8rc, 0, 16, 9
The above folding is wrong. Before transformation, %2:g8rc is 32 bit value. After
transformation, %2:g8rc becomes a 64 bit value.
This patch fixes above issue.
Reviewed by: steven.zhang
Differential Revision: https://reviews.llvm.org/D71833
|
| |
|
|
|
|
|
|
|
|
|
| |
that 'and' with constant
More patches will be committed later to exploit more about 'and' with
constant.
Differential Revision: https://reviews.llvm.org/D71693
|
|
|
|
|
|
|
|
| |
Reviewer: kbarton, jdoerfert
Reviewed By: jdoerfert
Subscribers: hiraditya, llvm-commits
Tag: LLVM
Differential Revision: https://reviews.llvm.org/D71878
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
If we didn't set the value for hasSideEffects bit in our td file, `llvm-tblgen`
will set it as true for those instructions which has no match pattern.
The instructions `MTLR` and `MFLR` don't set the hasSideEffects flag and don't
have match pattern, so their hasSideEffects flag will be set true by
`llvm-tblgen`.
But in fact, we can use `[LR]` to model the two instructions, so they should not
have SideEffects.
This patch is to modify the hasSideEffects of MTLR and MFLR from 1 to 0.
Reviewed By: jsji
Differential Revision: https://reviews.llvm.org/D71390
|
|
|
|
|
|
|
|
| |
kinds"
This reverts commit 2e6c15d1e7a47f11fab2dd3a40fcff01906923ae.
It causes the test to fail on Windows
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: Enable STRICT_SINT_TO_FP/STRICT_UINT_TO_FP on X86 backend
Reviewers: craig.topper, RKSimon, LiuChen3, uweigand, andrew.w.kaylor
Subscribers: hiraditya, llvm-commits, LuoYuanke
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D71871
|
|
|
|
| |
This reverts commit cb6e84fe3682f934bb6c1c6b55c3afee4f684774.
|
| |
|
|
|
|
|
|
|
|
|
| |
This patch combines the `emitParallel` logic prototyped in D61953 with
the OpenMPIRBuilder (D69785) and introduces `CreateParallel`.
Reviewed By: fghanim
Differential Revision: https://reviews.llvm.org/D70109
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: The specific number of records loaded depends on the number of kinds, but the difference between the lazy and not lazy cases does not.
Reviewers: modocache
Subscribers: mehdi_amini, hiraditya, steven_wu, dexonsmith, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D71730
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
As a permanent and generic solution to the problem of variable
finalization (destructors, lastprivate, ...), this patch introduces the
finalization stack. The objects on the stack describe (1) the
(structured) regions the OpenMP-IR-Builder is currently constructing,
(2) if these are cancellable, and (3) the callback that will perform the
finalization (=cleanup) when necessary.
As the finalization can be necessary multiple times, at different source
locations, the callback takes the position at which code is currently
generated. This position will also encode the destination of the "region
exit" block *iff* the finalization call was issues for a region
generated by the OpenMPIRBuilder. For regions generated through the old
Clang OpenMP code geneneration, the "region exit" is determined by Clang
inside the finalization call instead (see getOMPCancelDestination).
As a first user, the parallel + cancel barrier interaction is changed.
In contrast to the temporary solution before, the barrier generation in
Clang does not need to be aware of the "CancelDestination" block.
Instead, the finalization callback is and, as described above, later
even that one does not need to be.
D70109 will be updated to use this scheme.
Reviewed By: ABataev
Differential Revision: https://reviews.llvm.org/D70258
|
|
|
|
|
|
|
|
| |
v2i1->v2f64 on targets with AVX512F, but not AVX512VL.
In the worst case, this requires a 128-bit move instruction to
implicitly zero the upper bits. In the common case, we should
recognize the producing instruction already zeroed the upper bits.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
we're scanning the basic block instead of looking back for it.
Summary:
We're already scanning forward through the basic block. Might as
well just remember eflags defs instead of doing a bounded search
backwards later.
Based on a comment in D71841.
Reviewers: RKSimon, spatel, uweigand
Reviewed By: uweigand
Subscribers: hiraditya, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D71865
|
|
|
|
| |
ClangASTContext::GetBuiltinTypeForDWARFEncodingAndBitSize
|
|
|
|
| |
STRICT_CVTTP2SI/STRICT_CVTTP2UI nodes. NFC
|
|
|
|
|
|
| |
Reviewed By: grimar
Differential Revision: https://reviews.llvm.org/D71803
|
|
|
|
| |
Fixes build on NetBSD 9.0.
|
|
|
|
|
|
|
|
|
|
|
| |
Summary of changes:
- added description of GFX9 subtargets:
- gfx900;
- gfx902;
- gfx904;
- gfx906;
- gfx908;
- gfx909.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This cleans up and merges `gnu-symbols.test` to `symbols.test`.
Initially `gnu-symbols.test` tested the following things:
1) How symbols are printed in GNU style.
It does not make sense to have a separate file for such tests.
2) It tried to test proc-specific symbol indexes. The test was incomplete and
also we already have `symbol-shndx.test` for that, so this part was removed.
3) It tested `--dyn-symbols` and `--symbols` correlation. All following
cases were moved to `symbols.test`:
a) That `--dyn-symbols` does not trigger showing regular symbols..
b) That `--symbols` triggers `--dyn-symbols` implicitly.
c) That `--dyn-symbols` and `--symbols` works fine together.
Differential revision: https://reviews.llvm.org/D71697
|
|
|
|
|
|
|
|
| |
EI_ABIVERSION fields of an ELF header.
We had no separate tests for these fields.
Differential revision: https://reviews.llvm.org/D71766
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D71867
|
|
|
|
|
|
|
|
|
|
| |
Reviewers: rriddle
Reviewed By: rriddle
Subscribers: mehdi_amini
Differential Revision: https://reviews.llvm.org/D71853
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
constant or undef
Summary:
As discussed in D71799, we have found that it is more useful to reach an optimistic fixpoint in AAValueSimpify when the value is constant or undef.
Reviewers: jdoerfert, sstefan1
Reviewed By: jdoerfert
Subscribers: baziotis, hiraditya, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D71852
|
|
|
|
| |
EFLAGS use/def instead of our own custom operand scan. NFCI
|
|
|
|
|
| |
The TLS base (LWP private pointer) functions are namespaced and
hidden i.e. inside the _RTLD_SOURCE namespace.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
through a pointer
Summary:
Follow-up on: https://reviews.llvm.org/D71435
We basically use `checkForAllInstructions` to loop through all the instructions in a function that access memory through a pointer: load, store, atomicrmw, atomiccmpxchg
Note that we can now use the `getPointerOperand()` that gets us the pointer operand for an instruction that belongs to the aforementioned set.
Question: This function returns `nullptr` if the instruction is `volatile`. Why?
Guess: Because if it is volatile, we don't want to do any transformation to it.
Another subtle point is that I had to add AtomicRMW, AtomicCmpXchg to `initializeInformationCache()`. Following `checkAllInstructions()` path, that
seemed the most reasonable place to add it and correct the fact that these instructions were ignored (they were not in `OpcodeInstMap` etc.). Is that ok?
Reviewers: jdoerfert, sstefan1
Reviewed By: jdoerfert, sstefan1
Subscribers: hiraditya, jfb, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D71787
|