| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
|
|
Follow-up to 05ba5c0648ae5e80d5afce270495bf3b1eef9af4. uint32_t is
preferred over const MCExpr * in the section stack uses because it
should only be evaluated once. Change the paramter type to match.
|
|
If f(Y) simplifies to Y, replace with Y. This requires Y to be
non-undef.
Closes #94719
|
|
|
|
|
|
This change is part of this proposal:
https://discourse.llvm.org/t/rfc-all-the-math-intrinsics/78294
This is part 3 of 4 PRs. It sets the ground work for using the
intrinsics in HLSL.
Add HLSL frontend apis for `acos`, `asin`, `atan`, `cosh`, `sinh`, and
`tanh`
https://github.com/llvm/llvm-project/issues/70079
https://github.com/llvm/llvm-project/issues/70080
https://github.com/llvm/llvm-project/issues/70081
https://github.com/llvm/llvm-project/issues/70083
https://github.com/llvm/llvm-project/issues/70084
https://github.com/llvm/llvm-project/issues/95966
|
|
https://reviews.llvm.org/D67249 added content hash (see
-fvalidate-ast-input-files-content) using llvm::hash_code (size_t).
The hash value is 32-bit on 32-bit systems, which was unintentional.
Fix #96379: #96136 switched the hash function to xxh3_64bit but did not
update the ContentHash type, leading to mismatch between ASTReader and
ASTWriter.
|
|
|
|
|
|
There is only one caller after #95188.
|
|
#95197 and 75006466296ed4b0f845cbbec4bf77c21de43b40 eliminated all raw
`new MCXXXFragment`. We can now place fragments in a bump allocator.
In addition, remove the dead `Kind == FragmentType(~0)` condition.
~CodeViewContext may call `StrTabFragment->destroy()` and need to be
reset before `FragmentAllocator.Reset()`.
Tested by llvm/test/MC/COFF/cv-compiler-info.ll using asan.
Pull Request: https://github.com/llvm/llvm-project/pull/96402
|
|
|
|
format_provider (#95704)
The original implementation of HelperFunctions::consumeHexStyle always
sets Style when it returns true, but this is difficult for a compiler
to understand since it requires seeing that Str starts
with either an "x" or an "X" when starts_with_insensitive("x")
return true.
In particular, g++ 12 warns that HS may be used uninitialized
in the format_provider::format caller.
Change HelperFunctions::consumeHexStyle to return an optional
HexPrintStyle and to make the fact that Str necessarily starts
with an "X" when all other cases do not apply more explicit.
This helps both the compiler and the human reader of the code.
Co-authored-by: Sven Verdoolaege <sven.verdoolaege@gmail.com>
|
|
Reapply 4a7bf42a9b83144db8a11ac06cce4da21166e6a2
which was reverted in 34d44eb41dfbbbf01712719558b02763334fbeb3
Not sure why there are tests elsewhere in clang that rely on the output
of clang-format, but they were wrong
|
|
The checks when building a thunk to decide if an arg needed to be cast
to/from an integer or redirected via a pointer didn't match how arg
types were changed in `canonicalizeThunkType`, this caused LLVM to ICE
when using vector types as args due to incorrect types in a call
instruction.
Instead of duplicating these checks, we should check if the arg type
differs between x64 and AArch64 and then cast or redirect as
appropriate.
|
|
This was added by 507efbcce03d8c2c5dbea3028bc39f02c88fea79
([MC] Fold A-B when A is a pending label or A/B are separated by a
MCFillFragment) to account for pending labels and is now unneeded after
the removal of pending labels (75006466296ed4b0f845cbbec4bf77c21de43b40).
|
|
We're ultimately expected to return an APValue simply pointing to
the CallExpr, not any useful value. Do that by creating a global
variable for the call.
|
|
Fold `mul (uitofp i1 X), Y` to `select i1 X, Y, 0.0` when the `mul` is
`nnan` and `nsz`
Proof: https://alive2.llvm.org/ce/z/_stiPm
|
|
|
|
This formatter doesn't currently provide much value. It only formats
`SourceLocation` and `QualType`. The only formatting it does for
`QualType` is call `getAsString()` on it.
The main motivator for the removal however is that the formatter
implementation can be very slow (since it uses the expression evaluator
in non-trivial ways).
Not infrequently do we get reports about LLDB being slow when debugging
Clang, and it turns out the user was loading `ClangDataFormat.py` in
their `.lldbinit` by default.
We should eventually develop proper formatters for Clang data-types, but
these are currently not ready. So this patch removes them in the
meantime to avoid users shooting themselves in the foot, and giving the
wrong impression of these being reference implementations.
|
|
When unifying the ResolveExecutable implementations in #96256, I missed
that RemoteAwarePlatform was able to resolve executables more
aggressively. The host platform can rely on the current working
directory to make relative paths absolute and resolve things like home
directories.
This should fix command-target-create-resolve-exe.test.
|
|
declaration" (#96388)
Reverts llvm/llvm-project#95025 ; many bots are broken
|
|
Buildbot `clang-ppc64le-rhel` failed with:
```sh
error: 'MFPropsModifier' may not intend to support class template argument deduction [-Werror,-Wctad-maybe-unsupported]
note: add a deduction guide to suppress this warning
```
after #94854. This PR adds deduction guide explicitly to suppress
warning.
|
|
In ContinuationIndenter::mustBreak, a break is required between a
template declaration and the function/class declaration it applies to,
if the template declaration spans multiple lines.
However, this also includes template template parameters, which can
cause extra erroneous line breaks in some declarations.
This patch makes template template parameters not be counted as template
declarations.
Fixes https://github.com/llvm/llvm-project/issues/93793
Fixes https://github.com/llvm/llvm-project/issues/48746
|
|
RAII class (#94854)
Modify MachineFunctionProperties in PassModel makes `PassT P;
P.run(...);` not work properly. This is a necessary compromise.
|
|
This patch adds a variant of getValueProfDataFromInst that returns
std::vector<InstrProfValueData> instead of
std::unique<InstrProfValueData[]>. The new return type carries the
length with it, so we can drop out parameter ActualNumValueData.
Also, the caller can directly feed the return value into a range-based
for loop as shown in the patch.
I'm planning to migrate other callers of getValueProfDataFromInst to
the new variant in follow-up patches.
|
|
This commit removes the complexity introduced by pending labels in
https://reviews.llvm.org/D5915 by using a simpler approach. D5915 aimed
to ensure padding placement before `.Ltmp0` for the following code, but
at the cost of expensive per-instruction `flushPendingLabels`.
```
// similar to llvm/test/MC/X86/AlignedBundling/labeloffset.s
.bundle_lock align_to_end
calll .L0$pb
.bundle_unlock
.L0$pb:
popl %eax
.Ltmp0: //// padding should be inserted before this label instead of after
addl $_GLOBAL_OFFSET_TABLE_+(.Ltmp0-.L0$pb), %eax
```
(D5915 was adjusted by https://reviews.llvm.org/D8072 and
https://reviews.llvm.org/D71368)
This patch achieves the same goal by setting the offset of the empty
MCDataFragment (`Prev`) in `layoutBundle`. This eliminates the need for
pending labels and simplifies the code.
llvm/test/MC/MachO/pending-labels.s (D71368): relocation symbols are
changed, but the result is still supported by linkers.
|
|
requirements (#95651)
fixes https://github.com/llvm/llvm-project/issues/93788 .
|
|
This caused the MCOperand to be returned in memory. An MCOperand is only
16 bytes and therefore can be returned in registers on x86-64 and
AArch64 (and others).
|
|
|
|
Tested by lld/test/COFF/safeseh*.s but not by llvm/test/**
|
|
emitLabelAtPos is only called by ARMELFStreamer with MCDataFragment.
|
|
implemented by language plugins (#96290)
This patch adds a new `DoPrepareForExecution` API, which can be
implemented by the Clang and Swift language plugins. This also moves
`RunStaticInitializers` into `ExpressionParser::PrepareForExecution`, so
we call it consistently between language plugins.
This *should* be mostly NFC (the static initializers will still only run
after we finished parsing). We've been living on this patch downstream
for sometime now.
rdar://130267058
|
|
|
|
|
|
|
|
|
|
|
|
This patch handles various cases where an operation of the kind `icmp
(ucmp/scmp x, y), constant` folds to `icmp x, y`. Another patch with
cases where this operation folds to a constant (i.e. dumb cases like
`icmp eq (cmp x, y), 4` should be published in a couple of days.
I wasn't sure what negative tests should be added here, if any are
necessary at all. I'd love to hear your suggestions.
Proofs (ucmp): https://alive2.llvm.org/ce/z/qQ7ihz
Proofs (scmp): https://alive2.llvm.org/ce/z/cipKEn
---------
Co-authored-by: Nikita Popov <github@npopov.com>
|
|
conditional. (#96373)
|
|
Fixes #96096.
|
|
baremetal. (#96372)
Downstream build issue reported:
https://ci.chromium.org/ui/p/fuchsia/builders/toolchain.ci/clang-linux-x64/b8744479865106393873/overview
|
|
(#95879)
- Add `MachineDominatorTreeAnalysis`
- Add `MachineDominatorTreePrinterPass` There is no test for this
analysis in codebase.
Also, the pass name is renamed to `machine-dom-tree` instead of
`machinedomtree`.
|
|
Part of the test did not run due to an incorrect prefix.
The test was added in [D27629](https://reviews.llvm.org/D27629).
|
|
`rmw_or` is defined as "private alwaysinline". At the moment, it has
just only simple "Read, Or, and Write", which is just same as the
current implementation.
|
|
|
|
When building hwasan on aarch64, the DT_AARCH64_BTI_PLT flag is missing
from libclang_rt.hwasan.so because some object files without
DT_AARCH64_BTI_PLT are linked in the final DSO.
These files are specific to riscv64 and x86_64, ending up with no
aarch64 code in them.
Avoid building and linking architecture-specific files unless the
architecture is listed in HWASAN_SUPPORTED_ARCH.
|
|
When two or more functions' signatures differ, one of them is selected
and for other signatures `unreachable` stubs are generated:
https://github.com/llvm/llvm-project/blob/57778ec36c9c7e96b76a167f19dccbe00d49c9d4/lld/wasm/SymbolTable.cpp#L975
https://github.com/llvm/llvm-project/blob/57778ec36c9c7e96b76a167f19dccbe00d49c9d4/lld/wasm/SymbolTable.cpp#L852-L870
And when these `SyntheticFunction`s are generated, this constructor is
used,
https://github.com/llvm/llvm-project/blob/57778ec36c9c7e96b76a167f19dccbe00d49c9d4/lld/wasm/InputChunks.h#L266-L269
which does not set its `function` field:
https://github.com/llvm/llvm-project/blob/57778ec36c9c7e96b76a167f19dccbe00d49c9d4/lld/wasm/InputChunks.h#L304
As a result, the `function` field contains a garbage value for these
stub functions.
`InputFunction::getFunctionCodeOffset()` is called when relocations are
resolved for `.debug_info` section to get functions' PC locations. But
because these stub functions don't have their `function` field set, this
function segfaults:
https://github.com/llvm/llvm-project/blob/57778ec36c9c7e96b76a167f19dccbe00d49c9d4/lld/wasm/InputChunks.h#L282
This bug seems to be triggered when these conditions are met:
- There is a signature mismatch warning with multiple different
definitions (one definition with other declarations is not sufficient)
with weak linkage with the same name
- The 'stub' function containing unreachable has a callsite, meaning it
isn't DCE'd
- .debug_info section is generated (i.e., DWARF is used)
This PR initializes the field with `nullptr`, and in
`InputFunction::getFunctionCodeOffset`, checks if `function` is
`nullptr`, and if so, just returns 0. This function is called only for
resolving relocations in the `.debug_info` section, and addresses of
these stub functions, which are not the functions users wrote in the
first place, are not really meaningful anyway.
|
|
occurs" (#96365)
Reverts llvm/llvm-project#93023
Reverting due to buildbot failure.
https://lab.llvm.org/buildbot/#/builders/41/builds/227
test-suite ::
Fortran/gfortran/regression/gfortran-regression-execute-regression__execute_command_line_3_f90
|
|
If we have a bitwise negated inline immediate, we can materialize
it with s_not_b32/v_not_b32. This mirrors the current bitreverse
handling.
As a side effect, we also now handle the bitreversed FP immediate
case.
One test shows some VOPD regressions on gfx11 which should
probably be fixed. Previously the 2 v_mov_b32 could be packed,
but now the mismatched opcode + mov can't. This problem already
already existed for the bfrev case, it just happens more often now.
|
