```
<...>/TestGetControlFlowKindx86.cpp:148:8: warning: suggest explicit braces to avoid ambiguous ‘else’ [-Wdangling-else]
148 | if (kind == eInstructionControlFlowKindReturn)
| ^
```
Usually llvm is a "no braces for single line body" project but
for whatever reason gcc objects to it here. Perhaps because it's
within a for loop.
Added the newlines just for readability.
Add a dummy resolver to resolve references outside records. This invokes
Fold() with isFinal to force resolution.
Fixes#102447
Co-authored-by: Akshat Oke <Akshat.Oke@amd.com>
Fix 32-bit integer overflows in the X86 target frame layout when dealing
with frames larger than 4gb. When this occurs, we'll scavenge a scratch
register to be able to hold the correct stack offset for frame locals.
This completes reapplying #84114.
Fixes#48911Fixes#75944Fixes#87154
As far as I can tell, this has always been unused. My hunch is that
this was supposed to mimick the `MultiplexExternalSemaSource::AddSource`
API which `SemaSourceWithPriorities` is based on.
When building with gcc I get this warning:
```
<...>TestBreakpointSetCallback.cpp:58:25: warning: cast from type ‘const char*’ to type ‘void*’ casts away qualifiers [-Wcast-qual]
58 | void *baton = (void *)"hello";
| ^~~~~~~
```
Use the address of a mutable global variable instead. All we care about
is that the address passed as the baton is the same one we get later.
Follow up on 5627794 (MathExtras: avoid unnecessarily widening types) to
change the overflow behavior of alignToPowerOf2 to only overflow if the
result is not representable in the return type. This allows us to
template'ize it, and avoid unnecessarily widening the types of
arguments.
- Introduce primitives for removing records from `APISet` and managing
the record chain of `RecordContext`
- Detect nested anonymous record types and remove them from the `APISet`
after they have been fully traversed and transfer ownership of child
records to the parent context (if any)
This patch replaces getAs with castAs in
encodeTypeForFunctionPointerAuth to prevent dereferencing a potential
null pointer, enhancing type safety as reported by static analyzer tool.
The SiFiveP400 scheduler model did not support vector or vector crypto.
With the addition of the sifive-p470 processor, this model needs to support
these extensions.
The processors who use this model but do not have vector or vector
crypto will never produce these instructions, so there is no impact to these
processors.
Co-authored-by: Min Hsu <min.hsu@sifive.com>
This patch fixes a couple of cases where Clang aborts with loop nests
that are being collapsed (via the relevant OpenMP clause) into a new,
combined loop.
The problematic cases happen when a variable declared within the loop
nest is used in the (init, condition, iter) statement of a more
deeply-nested loop. I don't think these cases (generally?) fall under
the non-rectangular loop nest rules as defined in OpenMP 5.0+, but I
could be wrong (and anyway, emitting an error is better than crashing).
In terms of implementation: the crash happens because (to a first
approximation) all the loop bounds calculations are pulled out to the
start of the new, combined loop, but variables declared in the loop nest
"haven't been seen yet". I believe there is special handling for
iteration variables declared in "for" init statements, but not for
variables declared elsewhere in the "imperfect" parts of a loop nest.
So, this patch tries to diagnose the troublesome cases before they can
cause a crash. This is slightly awkward because at the point where we
want to do the diagnosis (SemaOpenMP.cpp), we don't have scope
information readily available. Instead we "manually" scan through the
AST of the loop nest looking for var decls (ForVarDeclFinder), then we
ensure we're not using any of those in loop control subexprs
(ForSubExprChecker). All that is only done when we have a "collapse"
clause.
Range-for loops can also cause crashes at present without this patch, so
are handled too.
Using X86ISD::SUB nodes directly allows us to drive the X86ISD::CMOV node with exact flags instead of trying to cleanup the generic codegen via ICMP/SUBO nodes.
Currently, the SLP schedule has two containers of `ScheduleData`:
`ExtraScheduleDataMap` and `ScheduleDataMap`. However, the
`ScheduleData` in `ExtraScheduleDataMap` is only used to indicate
whether the instruction is processed or not and does not participate in
the schedule, which is useless. `ScheduleDataMap` is sufficient for this
purpose. The `OpValue` member is used only in `ExtraScheduleDataMap`,
which is also useless.
As suggested in https://github.com/llvm/llvm-project/pull/103033, more
accurately rename to getPlanFor , as it simplify returns the VPlan for
VF, relying on the fact that there is a single VPlan for each VF at the
moment.
This patch adds the aforementioned fold to InstCombine. This pattern is
produced after naive implementations of 3-way comparison in high-level
languages are transformed into LLVM IR and then optimized.
Proofs: https://alive2.llvm.org/ce/z/w4QLq_
As suggested in https://github.com/llvm/llvm-project/pull/103033, add a
remark when the UserVF is ignored due to it being larger than MaxUserVF.
Only changes behavior of diagnostic/debug output.
By adding a new entrypoint, `LLVMRunPassesOnFunction`, as suggested in
https://discourse.llvm.org/t/newpm-c-api-questions/80598.
Also removes erroneous `LLVMConsumeError`s from the pass builder unit
tests as the string conversion already consumes the error, causing an
abort when the test would fail.
This was comparing some .size() (uint64_t) against the sizeof a size_t
which changes with system bitness. This produced a warning that
brought this to my attention.
These tests were failing too on 32 bit Arm only:
lld :: MachO/objc-category-merging-complete-test.s
lld :: MachO/objc-category-merging-minimal.s
The assert I think meant to check the value of target->wordSize,
not the size of its type. Which is a type that changes size between
systems.
For llvm_linux platform, define the following meaning for bits 9, 10,
11:
- bit 9: set if indirect gotos signing is enabled;
- bit 10: set if type info vtable pointer discrimination is enabled;
- bit 11: set if function pointer type discrimination is enabled.
This commit changes the LLVM dialect's inliner interface to properly
propagate noalias information to memory accesses that have different
underlying object. By always introducing an SSACopy intrinsic, it's
possible to understand that specific memory operations are using
unrelated pointers. Previously, the backwards slice walk did continue
beyond the boundary of the original function and failed to reason about
the "underlying objects".
AMD refer to them as microcoded, but not in the same way as LLVM - the uop count and pipe usage is high but predictable
Confirmed with Agner + uops.info.
This appears to be a copy+paste error from znver1 (which isn't really microcoded either - but it is rather complex!).
Confirmed with Agner + uops.info.
Members not requiring access to LoopVectorizationLegality or
LoopVectorizationCostModel can safely be moved out of the very large
LoopVectorization.cpp and are more accurately placed in VPlan.cpp
SimplifyCFG sinking currently does not sink loads/stores of allocas,
because historically SROA was unable to handle the resulting IR. Since
then, SROA both learned to speculate loads/stores over selects and phis,
*and* SimplifyCFG sinking has been deferred to the end of the function
simplification pipeline, which means that SROA happens before it.
As such, I believe that this workaround should no longer be necessary.
Given how sensitive SimplifyCFG sinking seems to be, this patch takes a
very conservative step towards removing this, by allowing sinking if we
don't actually need to form a phi over the pointer argument.
This fixes https://github.com/llvm/llvm-project/issues/104567, where
sinking a store to an escaped alloca allows converting a switch into
arithmetic.
This patch adds a pass that provides workarounds for the errata
described in GRLIB-TN-0009, GRLIB-TN-0010, GRLIB-TN-0011, GRLIB-TN-0012,
and GRLIB-TN-0013, that are applicable to the GR712RC and UT700. The
documents are available for download from here:
https://www.gaisler.com/index.php/information/app-tech-notes
The pass will detect certain sensitive instruction sequences and prevent
them from occurring by inserting NOP instruction. Below is an overview
of each of the workarounds. A similar implementation is available in
GCC.
GRLIB-TN-0009:
* Insert NOPs to prevent the sequence (stb/sth/st/stf) -> (single
non-store/load instruction) -> (any store)
* Insert NOPs to prevent the sequence (std/stdf) -> (any store)
GRLIB-TN-0010:
* Insert a NOP between load instruction and atomic instruction (swap and
casa).
* Insert a NOP at branch target if load in delay slot and atomic
instruction at branch target.
* Do not allow functions to begin with atomic instruction.
GRLIB-TN-0011:
* Insert .p2align 4 before atomic instructions (swap and casa).
GRLIB-TN-0012:
* Place a NOP at the branch target of an integer branch if it is a
floating-point operation or a floating-point branch.
GRLIB-TN-0013:
* Prevent (div/sqrt) instructions in the delay slot.
* Insert NOPs to prevent the sequence (div/sqrt) -> (two or three
floating point operations or loads) -> (div/sqrt).
* Do not insert NOPs if any of the floating point operations have a
dependency on the destination register of the first (div/sqrt).
* Do not insert NOPs if one of the floating point operations is a
(div/sqrt).
* Insert NOPs to prevent (div/sqrt) followed by a branch.
