<feed xmlns='http://www.w3.org/2005/Atom'>
<title>llvm-project.git/llvm/lib/Target/PowerPC/Disassembler, branch users/nico/python-2</title>
<subtitle>Unnamed repository; edit this file 'description' to name the repository.
</subtitle>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/'/>
<entry>
<title>[llvm] annotate interfaces in llvm/Target for DLL export (#143615)</title>
<updated>2025-06-17T20:28:45+00:00</updated>
<author>
<name>Andrew Rogers</name>
<email>andrurogerz@gmail.com</email>
</author>
<published>2025-06-17T20:28:45+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=19658d14749876cf0b6633f210c923be3709323b'/>
<id>19658d14749876cf0b6633f210c923be3709323b</id>
<content type='text'>
## Purpose

This patch is one in a series of code-mods that annotate LLVM’s public
interface for export. This patch annotates the `llvm/Target` library.
These annotations currently have no meaningful impact on the LLVM build;
however, they are a prerequisite to support an LLVM Windows DLL (shared
library) build.

## Background

This effort is tracked in #109483. Additional context is provided in
[this
discourse](https://discourse.llvm.org/t/psa-annotating-llvm-public-interface/85307),
and documentation for `LLVM_ABI` and related annotations is found in the
LLVM repo
[here](https://github.com/llvm/llvm-project/blob/main/llvm/docs/InterfaceExportAnnotations.rst).

A sub-set of these changes were generated automatically using the
[Interface Definition Scanner (IDS)](https://github.com/compnerd/ids)
tool, followed formatting with `git clang-format`.

The bulk of this change is manual additions of `LLVM_ABI` to
`LLVMInitializeX` functions defined in .cpp files under llvm/lib/Target.
Adding `LLVM_ABI` to the function implementation is required here
because they do not `#include "llvm/Support/TargetSelect.h"`, which
contains the declarations for this functions and was already updated
with `LLVM_ABI` in a previous patch. I considered patching these files
with `#include "llvm/Support/TargetSelect.h"` instead, but since
TargetSelect.h is a large file with a bunch of preprocessor x-macro
stuff in it I was concerned it would unnecessarily impact compile times.

In addition, a number of unit tests under llvm/unittests/Target required
additional dependencies to make them build correctly against the LLVM
DLL on Windows using MSVC.

## Validation

Local builds and tests to validate cross-platform compatibility. This
included llvm, clang, and lldb on the following configurations:

- Windows with MSVC
- Windows with Clang
- Linux with GCC
- Linux with Clang
- Darwin with Clang</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
## Purpose

This patch is one in a series of code-mods that annotate LLVM’s public
interface for export. This patch annotates the `llvm/Target` library.
These annotations currently have no meaningful impact on the LLVM build;
however, they are a prerequisite to support an LLVM Windows DLL (shared
library) build.

## Background

This effort is tracked in #109483. Additional context is provided in
[this
discourse](https://discourse.llvm.org/t/psa-annotating-llvm-public-interface/85307),
and documentation for `LLVM_ABI` and related annotations is found in the
LLVM repo
[here](https://github.com/llvm/llvm-project/blob/main/llvm/docs/InterfaceExportAnnotations.rst).

A sub-set of these changes were generated automatically using the
[Interface Definition Scanner (IDS)](https://github.com/compnerd/ids)
tool, followed formatting with `git clang-format`.

The bulk of this change is manual additions of `LLVM_ABI` to
`LLVMInitializeX` functions defined in .cpp files under llvm/lib/Target.
Adding `LLVM_ABI` to the function implementation is required here
because they do not `#include "llvm/Support/TargetSelect.h"`, which
contains the declarations for this functions and was already updated
with `LLVM_ABI` in a previous patch. I considered patching these files
with `#include "llvm/Support/TargetSelect.h"` instead, but since
TargetSelect.h is a large file with a bunch of preprocessor x-macro
stuff in it I was concerned it would unnecessarily impact compile times.

In addition, a number of unit tests under llvm/unittests/Target required
additional dependencies to make them build correctly against the LLVM
DLL on Windows using MSVC.

## Validation

Local builds and tests to validate cross-platform compatibility. This
included llvm, clang, and lldb on the following configurations:

- Windows with MSVC
- Windows with Clang
- Linux with GCC
- Linux with Clang
- Darwin with Clang</pre>
</div>
</content>
</entry>
<entry>
<title>[PowerPC] Remove asserts from the disassembler.</title>
<updated>2023-05-24T17:22:23+00:00</updated>
<author>
<name>Stefan Pintilie</name>
<email>stefanp@ca.ibm.com</email>
</author>
<published>2023-05-24T16:33:54+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=11fbd0c6abc9c47714247b58d9d8b0ef12bf1a4e'/>
<id>11fbd0c6abc9c47714247b58d9d8b0ef12bf1a4e</id>
<content type='text'>
My previous patch had added a couple of asserts to the disassembler.
The problem with this is that the disassembler is not just used for the
text section it is also used to disassemble the data section of an
object where the bytes do not necessarily represent instructions. If the
data in the data section happens to look like an illegal instruction
then llvm-objdump will assert on data because it is finding an illegal
instruction that is not actually an instruction at all.

Reviewed By: nemanjai, #powerpc

Differential Revision: https://reviews.llvm.org/D149711
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
My previous patch had added a couple of asserts to the disassembler.
The problem with this is that the disassembler is not just used for the
text section it is also used to disassemble the data section of an
object where the bytes do not necessarily represent instructions. If the
data in the data section happens to look like an illegal instruction
then llvm-objdump will assert on data because it is finding an illegal
instruction that is not actually an instruction at all.

Reviewed By: nemanjai, #powerpc

Differential Revision: https://reviews.llvm.org/D149711
</pre>
</div>
</content>
</entry>
<entry>
<title>[PowerPC] Implement DFP add and sub instructions.</title>
<updated>2023-05-02T01:13:52+00:00</updated>
<author>
<name>Stefan Pintilie</name>
<email>stefanp@ca.ibm.com</email>
</author>
<published>2023-05-01T17:11:47+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=c74aec99aafa1183c208d07a6efd04f73ee1fd9d'/>
<id>c74aec99aafa1183c208d07a6efd04f73ee1fd9d</id>
<content type='text'>
Add the following Decimal Floating Point (DFP) instructions for PowerPC.
dadd, daddq, dsub, dsubq

In order to add these instructions a new register class for a pair
of floating point registers is added.

This patch is only to allow the user to specify the instructions in
assembly. There is no scheduling or patterns for the instructions.

Reviewed By: amyk

Differential Revision: https://reviews.llvm.org/D148597
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Add the following Decimal Floating Point (DFP) instructions for PowerPC.
dadd, daddq, dsub, dsubq

In order to add these instructions a new register class for a pair
of floating point registers is added.

This patch is only to allow the user to specify the instructions in
assembly. There is no scheduling or patterns for the instructions.

Reviewed By: amyk

Differential Revision: https://reviews.llvm.org/D148597
</pre>
</div>
</content>
</entry>
<entry>
<title>Simplify with hasFeature. NFC</title>
<updated>2023-02-18T02:22:24+00:00</updated>
<author>
<name>Fangrui Song</name>
<email>i@maskray.me</email>
</author>
<published>2023-02-18T02:22:24+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=432caca39a62f4d20b8f38c139a3a462ea2a7f77'/>
<id>432caca39a62f4d20b8f38c139a3a462ea2a7f77</id>
<content type='text'>
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
</pre>
</div>
</content>
</entry>
<entry>
<title>[PowerPC] Switch to by-name matching for instructions (part 2 of 2).</title>
<updated>2023-02-02T20:28:45+00:00</updated>
<author>
<name>James Y Knight</name>
<email>jyknight@google.com</email>
</author>
<published>2022-11-08T22:11:08+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=0be684ed97397ef06c1ba391df0cf84b87edb792'/>
<id>0be684ed97397ef06c1ba391df0cf84b87edb792</id>
<content type='text'>
This is a follow-on to https://reviews.llvm.org/D134073.

Currently, all of the "memri"-style complex operands, which contain
both a register and an immediate, are encoded into a single field in
the instruction definition. This requires complex encoders/decoders,
and instruction definitions that insert and extract the correct parts
of the bits.

Now, switch to naming and encoding/decoding the sub-operands
separately.

Thus, we can now disable useDeprecatedPositionallyEncodedOperands.

Reviewed By: barannikov88

Differential Revision: https://reviews.llvm.org/D137670
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This is a follow-on to https://reviews.llvm.org/D134073.

Currently, all of the "memri"-style complex operands, which contain
both a register and an immediate, are encoded into a single field in
the instruction definition. This requires complex encoders/decoders,
and instruction definitions that insert and extract the correct parts
of the bits.

Now, switch to naming and encoding/decoding the sub-operands
separately.

Thus, we can now disable useDeprecatedPositionallyEncodedOperands.

Reviewed By: barannikov88

Differential Revision: https://reviews.llvm.org/D137670
</pre>
</div>
</content>
</entry>
<entry>
<title>[PowerPC] Don't crash when disassembling invalid immediate</title>
<updated>2023-02-02T18:39:49+00:00</updated>
<author>
<name>Nemanja Ivanovic</name>
<email>nemanja.i.ibm@gmail.com</email>
</author>
<published>2023-02-02T18:38:08+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=c86f8d4276aee8956711829e49c9969cd0223590'/>
<id>c86f8d4276aee8956711829e49c9969cd0223590</id>
<content type='text'>
There is an assert in the disassembler functions to ensure
that the immediate is the appropriate width. However,
sometimes what is being disassembled is not instructions
but data that happens to have the bit pattern of an existing
instruction but invalid operands. It is valid for such
things to exist in the text section so we don't want
to crash when disassembling such a thing.

This patch removes the asserts and produces a disassembler
failure for such cases.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
There is an assert in the disassembler functions to ensure
that the immediate is the appropriate width. However,
sometimes what is being disassembled is not instructions
but data that happens to have the bit pattern of an existing
instruction but invalid operands. It is valid for such
things to exist in the text section so we don't want
to crash when disassembling such a thing.

This patch removes the asserts and produces a disassembler
failure for such cases.
</pre>
</div>
</content>
</entry>
<entry>
<title>[Target] Use llvm::count{l,r}_{zero,one} (NFC)</title>
<updated>2023-01-28T17:23:07+00:00</updated>
<author>
<name>Kazu Hirata</name>
<email>kazu@google.com</email>
</author>
<published>2023-01-28T17:23:07+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=e0782018352fc4d7e104e82edf380d895d4abdd5'/>
<id>e0782018352fc4d7e104e82edf380d895d4abdd5</id>
<content type='text'>
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
</pre>
</div>
</content>
</entry>
<entry>
<title>[NFC][CMake] Explicitly link to MC when needed</title>
<updated>2022-12-13T13:24:46+00:00</updated>
<author>
<name>Roman Lebedev</name>
<email>lebedev.ri@gmail.com</email>
</author>
<published>2022-12-13T13:13:34+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=a33ae9ac3593d999e16eacc8aa22e8bd8e220409'/>
<id>a33ae9ac3593d999e16eacc8aa22e8bd8e220409</id>
<content type='text'>
These targets use `MCInst`, but don't explicitly link
to the library providing it (MC), and just rely on it
being pulled transitively through e.g. MCDisassembler,
but that only pulls includes, and does not link to it.

Case in point, when i add explicit destructor to `MCInst`,
defined in `.cpp`, these targets were failing to link.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
These targets use `MCInst`, but don't explicitly link
to the library providing it (MC), and just rely on it
being pulled transitively through e.g. MCDisassembler,
but that only pulls includes, and does not link to it.

Case in point, when i add explicit destructor to `MCInst`,
defined in `.cpp`, these targets were failing to link.
</pre>
</div>
</content>
</entry>
<entry>
<title>[PowerPC] Add new DMR register classes to Future CPU.</title>
<updated>2022-11-03T13:29:55+00:00</updated>
<author>
<name>Stefan Pintilie</name>
<email>stefanp@ca.ibm.com</email>
</author>
<published>2022-11-02T14:55:54+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=9df924a634ac5ea702b0d8d0d8b737c819a98095'/>
<id>9df924a634ac5ea702b0d8d0d8b737c819a98095</id>
<content type='text'>
A new register class as well as a number of related subregisters are being added
to Future CPU. These registers are Dense Math Registers (DMR) and are 1024 bits
long. These regsiters can also be used in consecutive pairs which leads to a
register that is 2048 bits.

This patch also adds 7 new instructions that use these registers. More
instructions will be added in future patches.

Reviewed By: amyk, saghir

Differential Revision: https://reviews.llvm.org/D136366
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
A new register class as well as a number of related subregisters are being added
to Future CPU. These registers are Dense Math Registers (DMR) and are 1024 bits
long. These regsiters can also be used in consecutive pairs which leads to a
register that is 2048 bits.

This patch also adds 7 new instructions that use these registers. More
instructions will be added in future patches.

Reviewed By: amyk, saghir

Differential Revision: https://reviews.llvm.org/D136366
</pre>
</div>
</content>
</entry>
<entry>
<title>Rename `MCFixedLenDisassembler.h` as `MCDecoderOps.h`</title>
<updated>2022-05-15T00:44:58+00:00</updated>
<author>
<name>Sheng</name>
<email>ox59616e@gmail.com</email>
</author>
<published>2022-05-15T00:42:50+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=c644488a8b8a2e831c5665a6167a9debabbb2d72'/>
<id>c644488a8b8a2e831c5665a6167a9debabbb2d72</id>
<content type='text'>
The name `MCFixedLenDisassembler.h` is out of date after D120958.

Rename it as `MCDecoderOps.h` to reflect the change.

Reviewed By: myhsu

Differential Revision: https://reviews.llvm.org/D124987
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
The name `MCFixedLenDisassembler.h` is out of date after D120958.

Rename it as `MCDecoderOps.h` to reflect the change.

Reviewed By: myhsu

Differential Revision: https://reviews.llvm.org/D124987
</pre>
</div>
</content>
</entry>
</feed>
