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.
If any of the printed paths by llvm-config contain quotes, spaces,
backslashes or dollar sign characters, these paths will be quoted and
escaped, but only if using `--quote-paths`. The previous behavior is
retained for compatibility and `--quote-paths` is there to acknowledge
the migration to the new behavior.
Following discussion in #76304Fixes#28117
Superseeds https://github.com/llvm/llvm-project/pull/97305
I could also do what @tothambrus11 suggests in
https://github.com/llvm/llvm-project/pull/97305#issuecomment-2282847990
but that makes all Windows paths quoted & escaped since they all contain
backslashes.
All PDB tests now pass when compiled without DIA on Windows, so they
pass with the native reader.
With this PR, the default reader changes to the native reader.
The plan is to eventually remove the DIA reader (see
https://discourse.llvm.org/t/rfc-removing-the-dia-pdb-plugin-from-lldb/87827
and #114906).
For now, DIA can be used by setting `plugin.symbol-file.pdb.reader` to
`dia` or by setting `LLDB_USE_NATIVE_PDB_READER=0` (mostly undocumented,
but used in tests).
The `masked.load`, `masked.store`, `masked.gather` and `masked.scatter`
intrinsics currently accept a separate alignment immarg. Replace this
with an `align` attribute on the pointer / vector of pointers argument.
This is the standard representation for alignment information on
intrinsics, and is already used by all other memory intrinsics. This
means the signatures now match llvm.expandload, llvm.vp.load, etc.
(Things like llvm.memcpy used to have a separate alignment argument as
well, but were already migrated a long time ago.)
It's worth noting that the masked.gather and masked.scatter intrinsics
previously accepted a zero alignment to indicate the ABI type alignment
of the element type. This special case is gone now: If the align
attribute is omitted, the implied alignment is 1, as usual. If ABI
alignment is desired, it needs to be explicitly emitted (which the
IRBuilder API already requires anyway).
SIGWINCH is sent when the terminal window size changes.. Most people
debugging do not want the process on this signal.
When using lldb-dap, the user may be using an integrated terminal and
may resize the pane/window mulitple times when debugging. this causes
the signal to be sent multiple times. It gets in the way.
The process ignores this signal by default
-fpseudo-probe-for-profiling is supported for COFF in #123870.
llvm-profgen supports decoding pseudo probe in #158207.
This PR updates release note and adds an example to use it in
UsersManual.rst.
This PR adds support for emitting the OSC `9;4` sequences to show a GUI
native progress bar.
There's a limited number of terminal emulators that support this, so for
now this requires explicit opt-in through a setting. I'm reusing the
existing `show-progress` setting, which became a NOOP with the
introduction of the statusline. The option now defaults to off.
Implements #160369
Allow LLVMGetVolatile() to work with any kind of Instruction, rather
than only memory instructions that accept a volatile flag. For
instructions that can never be volatile, the function now return false
instead of asserting. This matches the behavior of
`Instruction::isVolatile()` in the C++ API.
Add `LLVMGetOrInsertFunction` to the C API as a thin wrapper over
`Module::getOrInsertFunction`, upstreamed from
[rustc](d773bd07d6/compiler/rustc_llvm/llvm-wrapper/RustWrapper.cpp (L203)).
It provides a single-call way to get or create a function declaration,
avoiding `LLVMGetNamedFunction` + `LLVMAddFunction` and is more
idiomatic.
Introduce `AllocToken`, an instrumentation pass designed to provide
tokens to memory allocators enabling various heap organization
strategies, such as heap partitioning.
Initially, the pass instruments functions marked with a new attribute
`sanitize_alloc_token` by rewriting allocation calls to include a token
ID, appended as a function argument with the default ABI.
The design aims to provide a flexible framework for implementing
different token generation schemes. It currently supports the following
token modes:
- TypeHash (default): token IDs based on a hash of the allocated type
- Random: statically-assigned pseudo-random token IDs
- Increment: incrementing token IDs per TU
For the `TypeHash` mode introduce support for `!alloc_token` metadata:
the metadata can be attached to allocation calls to provide richer
semantic
information to be consumed by the AllocToken pass. Optimization remarks
can be enabled to show where no metadata was available.
An alternative "fast ABI" is provided, where instead of passing the
token ID as an argument (e.g., `__alloc_token_malloc(size, id)`), the
token ID is directly encoded into the name of the called function (e.g.,
`__alloc_token_0_malloc(size)`). Where the maximum tokens is small, this
offers more efficient instrumentation by avoiding the overhead of
passing an additional argument at each allocation site.
Link: https://discourse.llvm.org/t/rfc-a-framework-for-allocator-partitioning-hints/87434 [1]
---
This change is part of the following series:
1. https://github.com/llvm/llvm-project/pull/160131
2. https://github.com/llvm/llvm-project/pull/156838
3. https://github.com/llvm/llvm-project/pull/162098
4. https://github.com/llvm/llvm-project/pull/162099
5. https://github.com/llvm/llvm-project/pull/156839
6. https://github.com/llvm/llvm-project/pull/156840
7. https://github.com/llvm/llvm-project/pull/156841
8. https://github.com/llvm/llvm-project/pull/156842
This patch removes support for %T from llvm-lit. For now we mark the
test unresolved and add an error message noting the substitution is
deprecated. This is exactly the same as the error handling for other
substitution failures. We intend to remove support for the nice error
message once 22 branches as users should have moved over by the they are
upgrading to v23.
Reviewers: petrhosek, jh7370, ilovepi, pogo59, cmtice
Reviewed By: cmtice, jh7370, ilovepi
Pull Request: https://github.com/llvm/llvm-project/pull/160028
Lit's builtin diff command had some Python 2.7 code paths lying around
that we can probably get rid of at this point. LLVM at this point
requires Python 3.8 at minimum. Keeping lit working at a lower version
is a reasonable goal, but I think we can probably drop python 2 support
at this point given how long it has been deprecated and how long LLVM
has supported Python 3.
Reviewers: jdenny-ornl, ilovepi, petrhosek
Reviewed By: ilovepi
Pull Request: https://github.com/llvm/llvm-project/pull/157558
Previously, llvm-readelf dumped hex format values in different ways.
Some of them were printed in upper-case, while the others were in
lower-case format. This change switches the format to lower-case in all
cases.
Why is this useful? As an example, FileCheck comparisons are
case-sensitive by default. This change means it's easier to compare
those values, because they have the same format.
The script copies `ReleaseNotesTemplate.txt` to corresponding
`ReleaseNotes.rst`/`.md` to clear release notes.
The suffix of `ReleaseNotesTemplate.txt` must be `.txt`. If it is
`.rst`/`.md`, it will be treated as a documentation source file when
building documentation.
Added initial check for potential fmad conversion in reductions and
operands vectorization.
Added the check for instruction to fix#152683
Skipped the code for reduction to avoid regressions.
This introduces a new `ptrtoaddr` instruction which is similar to
`ptrtoint` but has two differences:
1) Unlike `ptrtoint`, `ptrtoaddr` does not capture provenance
2) `ptrtoaddr` only extracts (and then extends/truncates) the low
index-width bits of the pointer
For most architectures, difference 2) does not matter since index (address)
width and pointer representation width are the same, but this does make a
difference for architectures that have pointers that aren't just plain
integer addresses such as AMDGPU fat pointers or CHERI capabilities.
This commit introduces textual and bitcode IR support as well as basic code
generation, but optimization passes do not handle the new instruction yet
so it may result in worse code than using ptrtoint. Follow-up changes will
update capture tracking, etc. for the new instruction.
RFC: https://discourse.llvm.org/t/clarifiying-the-semantics-of-ptrtoint/83987/54
Reviewed By: nikic
Pull Request: https://github.com/llvm/llvm-project/pull/139357
