This change turns the `"nooutline"` attribute into an enum attribute
called `nooutline`, and adds an auto-upgrader for bitcode to make the
same change to existing IR.
This IR attribute disables both the Machine Outliner (enabled at Oz for
some targets), and the IR Outliner (disabled by default).
Currently versions under 13 are EOLed (see [FreeBSD Release
Information](https://www.freebsd.org/releases/)).
FreeBSD 13 will be EOLed by April 30th (see [Supported FreeBSD
releases](https://www.freebsd.org/security/#sup)) while LLVM 23 is
expected to be released in August 25th according to the LLVM calendar.
Thus assumed that minimum supported FreeBSD version is 14.
Signed-off-by: Minsoo Choo <minsoochoo0122@proton.me>
The last FreeBSD version supporting mips64 is FreeBSD 13 which will be
EOLed on April 30th. LLVM 23.1.0 release is expected to be August 25th
according to the LLVM calendar. The usage of mips64 is less noticeable
so it's hard to know if it is properly working, and even if it works, it
is hard to test new features on FreeBSD mips64.
Thus, remove support for mips64 on FreeBSD.
---------
Signed-off-by: Minsoo Choo <minsoochoo0122@proton.me>
Convert "denormal-fp-math" and "denormal-fp-math-f32" into a first
class denormal_fpenv attribute. Previously the query for the effective
denormal mode involved two string attribute queries with parsing. I'm
introducing more uses of this, so it makes sense to convert this
to a more efficient encoding. The old representation was also awkward
since it was split across two separate attributes. The new encoding
just stores the default and float modes as bitfields, largely avoiding
the need to consider if the other mode is set.
The syntax in the common cases looks like this:
`denormal_fpenv(preservesign,preservesign)`
`denormal_fpenv(float: preservesign,preservesign)`
`denormal_fpenv(dynamic,dynamic float: preservesign,preservesign)`
I wasn't sure about reusing the float type name instead of adding a
new keyword. It's parsed as a type but only accepts float. I'm also
debating switching the name to subnormal to match the current
preferred IEEE terminology (also used by nofpclass and other
contexts).
This has a behavior change when using the command flag debug
options to set the denormal mode. The behavior of the flag
ignored functions with an explicit attribute set, per
the default and f32 version. Now that these are one attribute,
the flag logic can't distinguish which of the two components
were explicitly set on the function. Only one test appeared to
rely on this behavior, so I just avoided using the flags in it.
This also does not perform all the code cleanups this enables.
In particular the attributor handling could be cleaned up.
I also guessed at how to support this in MLIR. I followed
MemoryEffects as a reference; it appears bitfields are expanded
into arguments to attributes, so the representation there is
a bit uglier with the 2 2-element fields flattened into 4 arguments.
Per the psABI discussion in riscv-non-isa/riscv-elf-psabi-doc#474, the
conclusion was to NOT introduce a new build attribute for MOP/HINT
encoding reinterpretation. Instead, the toolchain should recognize these
mnemonics unconditionally in the assembler and disassembler.
The rationale is that these encodings occupy reserved hint/MOP space
that is architecturally guaranteed not to trap on any compliant
implementation. Requiring explicit extension flags creates unnecessary
friction for users who simply want to write or read these instructions,
while providing no real safety benefit since the encodings are always
valid.
Note: Ideally, the ISA specification would explicitly guarantee that
these MOP/HINT encodings will never be reassigned to conflicting
instructions. However, the ISA architects prefer to preserve flexibility
in this area rather than making such guarantees in the spec. Given the
practical reality that reassignment is highly unlikely, the toolchain
takes the pragmatic approach of always recognizing these mnemonics.
This change makes the following mnemonics always available:
- lpad (Zicfilp): AUIPC hint encoding, always valid
- pause (Zihintpause): FENCE hint encoding, always valid
- ntl.* (Zihintntl): ADD hint encoding, always valid
- c.ntl.* (Zihintntl+C): requires C extension only
- sspush/sspopchk/ssrdp (Zicfiss): requires Zimop only (MOP encoding)
- c.sspush/c.sspopchk (Zicfiss+Zcmop): requires Zcmop only
Note: ssamoswap.w/d still requires Zicfiss as they use AMO encoding
space rather than MOP encoding.
Codegen patterns remain unchanged in this patch - generating these
instructions in the compiler backend still requires the full extension
to be enabled. A follow-up patch will relax this restriction as well,
since these instructions are fundamentally MOP/HINT encodings that
should be safe to generate regardless of extension availability.
Link: https://github.com/riscv-non-isa/riscv-elf-psabi-doc/pull/474
There was no real benefit to disallowing this, and it sometimes caused
unnecessary churn in the RUN lines of tests which were updated from
single-to-multiple or multiple-to-single prefixes.
This effectively makes -check-prefixes the primary option and
-check-prefix just an alias of it. The documentation is upated
accordingly.
This adds support for `--symbolize-operands`, so that local references
are turned back into labels by objdump, which makes it easier to tell
what is going on with a linked object.
When using `--symbolize-operands`, branch target addresses are not
printed, only the referenced symbol is printed, and the address is
elided:
```
# Without --symbolize-operands
0: 04a05263 blez a0, 0x44 <.text+0x44>
...
40: fd1ff06f j 0x10 <.text+0x10>
44: 00000613 li a2, 0x0
# With --symbolize-operands
0: 04a05263 blez a0, <L3>
...
40: fd1ff06f j <L0>
<L3>:
44: 00000613 li a2, 0x0
```
This eases interoperability by making it explicit in emitted assembly code which syntax is used.
Refactored to remove X86-specific directives and logic from the generic MC(Asm)Streamer.
Motivated by building LLVM with `-mllvm -x86-asm-syntax=intel` (i.e. a global preference for Intel
syntax). A Bolt test (`runtime/X86/fdata-escape-chars.ll`) was using `llc` to compile to assembly
and then assembling with `clang`. The specific option causes Clang to assume Intel syntax but only
for assembly and not inline assembly.
These are long overdue for removal. These were originally a hack
to support loading half values before there was any / decent support
for the half type through the backend. There's no reason to continue
supporting these, they're equivalent to fpext/fptrunc with a bitcast.
SelectionDAG stopped translating these directly, and used the
bitcast + fp cast since f7a02c17628e825, so there's been no reason
to use these since 2014.
LLVM's existing support for chaining x64 Windows SEH frame infos is
broken. Windows requires that each frame info (including the parent) is
adjacent, but not overlapping, and the whole function is covered (i.e.,
each instruction maps to exactly one frame info). Therefore, having
start/end chaining pseudo instructions doesn't make any sense, as every
"end chain" pseudo would need a start pseudo immediately after it or be
at the end of function.
This change switches having a "split chain" pseudo instruction that ends
the current frame and starts a new chained frame.
Added a release note about the replacement - to my knowledge there is no
one actually using frame info chaining, so it is highly unlikely that it
will break any code.
Split off from #159206
We already had a few MSVC STL formatters at the last release, but we
postponed the release note entry until they support PDB. The formatters
now support PDB.
There are still some left (see
https://github.com/llvm/llvm-project/issues/24834#issuecomment-3049291996),
but the most common types are formatted.
This adds code to recognize "wasm32-wasip1", "wasm32-wasip2", and
"wasm32-wasip3" as explicit targets, and adds a deprecation warning when
the "wasm32-wasi" target is used, pointing users to the "wasm32-wasip1"
target.
Fixes#165344.
I'm filing this as a draft PR for now, as I've only just now proposed to
make this change in #165344.
This new function is the same as LLVMParseIRInContext except it doesn't
take ownership of the memory buffer. This fixes a wart that has been in
place since 5ebb7b311223bcd21d2b3d25413d1edacefcc63d changed the
underlying internal API to avoid taking ownership.
Reduce nesting in the implementation of LLVMParseIRInContext (now
LLVMParseIRInContext2) as well.
Update examples, OCaml bindings, and tests including plugging some
pre-existing memory leaks. OCaml bindings have renamed `parse_ir` to
`parse_ir_bitcode_or_assembly` to provoke compilation failures in
downstream code; this is intentional as this function now requires the
memory buffer to be disposed by the caller.
On PowerPC targets, `half` uses the default legalization of promoting to
a `f32`. However, this has some fundamental issues related to inability
to round trip. Resolve this by switching to the soft legalization, which
passes `f16` as an `i16`.
The PowerPC ABI Specification does not define a `_Float16` type, so the
calling convention changes are acceptable.
Fixes the PowerPC part of
https://github.com/llvm/llvm-project/issues/97975
Fixes the PowerPC part of
https://github.com/llvm/llvm-project/issues/97981
The default `half` legalization, which Wasm currently uses, does not
respect IEEE conventions: for example, casting to bits may invoke a lossy
libcall, meaning soft float operations cannot be correctly implemented.
Change to the soft promotion legalization which passes `f16` as an `i16`
and treats each `half` operation as an individual
f16->f32->libcall->f32->f16 sequence.
Of note in the test updates are that `from_bits` and `to_bits` are now
libcall-free, and that chained operations now round back to `f16` after
each step.
Fixes the wasm portion of
https://github.com/llvm/llvm-project/issues/97981
Fixes the wasm portion of
https://github.com/llvm/llvm-project/issues/97975
Fixes: https://github.com/llvm/llvm-project/issues/96437
Fixes: https://github.com/llvm/llvm-project/issues/96438
Version 0.13 of the Xqci Qualcomm uC Vendor Extension has been marked as
frozen. We've had assembler support for this since LLVM20 and code
generation support since LLVM21. I think we have enough coverage in the
code base to mark the extension as non-experimental.
Reland #165661 with fix for memory leak.
The call to `DummyTarget->createMCSubtargetInfo` within `mcpuHelp()`
returns a pointer that is not subsequently freed, leading to a memory
leak. Use `std::unique_ptr` to ensure the memory is released
automatically.
Original description:
---
Currently --mcpu=help and --mattr=help only produce help out when
disassembling. This patch specialises these cases to always print the
requested help.
If --triple is specified, the help text will be derived from the
specified target. Otherwise, it will be derived from the target of the
first input file.
Fixes: https://github.com/llvm/llvm-project/issues/150567
Currently `--mcpu=help` and `--mattr=help` only produce help out when
disassembling. This patch specialises these cases to always print the
requested help.
If `--triple` is specified, the help text will be derived from the
specified target. Otherwise, it will be derived from the target of the
first input file.
Fixes: #150567
---------
Signed-off-by: Ruoyu Qiu <cabbaken@outlook.com>
Co-authored-by: James Henderson <James.Henderson@sony.com>
This PR adds a platform for WebAssembly. Heavily inspired by Pavel's
QemuUser, the platform lets you configure a WebAssembly runtime to run a
Wasm binary.
For example, the following configuration can be used to launch binaries
under the WebAssembly Micro Runtime (WARM):
```
settings set -- platform.plugin.wasm.runtime-args --heap-size=1048576
settings set -- platform.plugin.wasm.port-arg -g=127.0.0.1:
settings set -- platform.plugin.wasm.runtime-path /path/to/iwasm-2.4.0
```
With the settings above, you can now launch a binary directly under
WAMR:
```
❯ lldb simple.wasm
(lldb) target create "/Users/jonas/wasm-micro-runtime/product-mini/platforms/darwin/build/simple.wasm"
Current executable set to '/Users/jonas/wasm-micro-runtime/product-mini/platforms/darwin/build/simple.wasm' (wasm32).
(lldb) b main
Breakpoint 1: 2 locations.
(lldb) r
Process 1 launched: '/Users/jonas/wasm-micro-runtime/product-mini/platforms/darwin/build/simple.wasm' (wasm32)
2 locations added to breakpoint 1
[22:28:05:124 - 16FE27000]: control thread of debug object 0x1005e9020 start
[22:28:05:124 - 16FE27000]: Debug server listening on 127.0.0.1:49170
the module name is /Users/jonas/wasm-micro-runtime/product-mini/platforms/darwin/build/simple.wasm
Process 1 stopped
* thread #1, name = 'nobody', stop reason = breakpoint 1.3
frame #0: 0x40000000000001d3 simple.wasm`main at simple.c:8:7
5 }
6
7 int main() {
-> 8 int i = 1;
9 int j = 2;
10 return add(i, j);
11 }
(lldb)
```
SwitchInst case values must be ConstantInt, which have no use list.
Therefore it is not necessary to store these as Use, instead store them
more efficiently as a simple array of pointers after the uses, similar
to how PHINode stores basic blocks.
After this change, the successors of all terminators are stored
consecutively in the operand list. This is preparatory work for
improving the performance of successor access.
Add new C API functions so that switch case values remain accessible
from bindings for other languages.
While this could also be achieved by merely changing the order of
operands (i.e., first all successors, then all constants), doing so
would increase the asymptotic runtime of addCase from O(1) to O(n)
(i.e., adding n cases would be O(n^2)), because it would need to shift
all constants by one slot. Having null/invalid operands is also a bad
idea and would cause much more breakage.
Pull Request: https://github.com/llvm/llvm-project/pull/170984
One of the most common mistakes when working with the LLVM C API is to
mix functions that work on the global context and those that work on an
explicit context. This often results in seemingly nonsensical errors
because types from different contexts are mixed.
We have considered the APIs working on the global context to be obsolete
for a long time already, and do not add any new APIs using the global
context. However, the fact that these still exist (and have shorter
names) continues to cause issues.
This PR proposes to deprecate these APIs, with intent to remove them at
some point in the future.
RFC:
https://discourse.llvm.org/t/rfc-deprecate-c-api-functions-using-the-global-context/88639
SwitchInst case values must be ConstantInt, which have no use list.
Therefore it is not necessary to store these as Use, instead store them
more efficiently as a simple array of pointers after the uses, similar
to how PHINode stores basic blocks.
After this change, the successors of all terminators are stored
consecutively in the operand list. This is preparatory work for
improving the performance of successor access.
This change adds the ability to create a 128 bit floating point value
from 2 64 bit integer values.
Some language frontends have already parsed a floating point string into
a proper 128 bit quad value
and need to get the llvm value directly.
The Transactional Memory Extension (TME) was introduced as part of
Armv9-A but has not been adopted by the ecosystem. This mirrors what
Arm has observed with similar extensions in other architectures.
Therefore, remove FEAT_TME assembly and ACLE code from llvm, because
support for TME has now been officially withdrawn, as noted here:
```
FEAT_TME is withdrawn from all future versions of Arm®
Architecture Reference Manual for A-profile architecture.
```
referenced in Known Issue D24093, documented here:
https://developer.arm.com/documentation/102105/lb-05/
This patch adds a Clang-compatible --save-stats option to opt, to
provide an easy to use way to save LLVM statistics files when working
with opt on the middle end.
This is a follow up on the addition to `llc`:
https://github.com/llvm/llvm-project/pull/163967
Like on Clang, one can specify --save-stats, --save-stats=cwd, and
--save-stats=obj with the same semantics and JSON format. The
pre-existing --stats option is not affected.
The implementation extracts the flag and its methods into the common
`CodeGen/CommandFlags` as `LLVM_ABI`, using a new registration class to
conservatively enable opt-in rather than let all tools take it. Its only
needed for llc and opt for now. Then it refactors llc and adds support
for opt.
A new InstCombine transform uses this attribute to rewrite calls to a
modular version of the implementation along with llvm.reloc.none
relocations against aspects of the implementation needed by the call.
This change only adds support for the 'float' aspect, but it also builds
the structure needed for others.
See issue #146159
This patch adds a Clang-compatible `--save-stats` option, to provide an
easy to use way to save LLVM statistics files when working with llc on
the backend.
Like on Clang, one can specify `--save-stats`, `--save-stats=cwd`, and
`--save-stats=obj` with the same semantics and JSON format.
The implementation uses 2 methods `MaybeEnableStats` and
`MaybeSaveStats` called before and after `compileModule` respectively
that externally own the statistics related logic, while `compileModule`
is now required to return the resolved output filename via an output
param.
Note: like on Clang, the pre-existing `--stats` option is not affected.
