<feed xmlns='http://www.w3.org/2005/Atom'>
<title>llvm-project.git/llvm/lib/Target/ARM/Thumb2SizeReduction.cpp, 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>[NFC][CodeGen] Adopt MachineFunctionProperties convenience accessors (#141101)</title>
<updated>2025-05-23T15:30:29+00:00</updated>
<author>
<name>Rahul Joshi</name>
<email>rjoshi@nvidia.com</email>
</author>
<published>2025-05-23T15:30:29+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=52c2e45c11ee37d8efcf87cbfa5c9f23cbdd566b'/>
<id>52c2e45c11ee37d8efcf87cbfa5c9f23cbdd566b</id>
<content type='text'>
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
</pre>
</div>
</content>
</entry>
<entry>
<title>[ARM] Remove unused includes (NFC) (#116155)</title>
<updated>2024-11-14T07:11:14+00:00</updated>
<author>
<name>Kazu Hirata</name>
<email>kazu@google.com</email>
</author>
<published>2024-11-14T07:11:14+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=5be43db9b17e7cfc9e987f257221b0926551eb6e'/>
<id>5be43db9b17e7cfc9e987f257221b0926551eb6e</id>
<content type='text'>
Identified with misc-include-cleaner.</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Identified with misc-include-cleaner.</pre>
</div>
</content>
</entry>
<entry>
<title>[ARM] Prefer MUL to MULS on some implementations (#112540)</title>
<updated>2024-10-17T12:53:22+00:00</updated>
<author>
<name>VladiKrapp-Arm</name>
<email>vladi.krapp@arm.com</email>
</author>
<published>2024-10-17T12:53:22+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=ea796e5237afbbef396b21ac04d4f32557c8db61'/>
<id>ea796e5237afbbef396b21ac04d4f32557c8db61</id>
<content type='text'>
MULS adversely affects performance on many implementations. Where this
is the case, we prefer not to shrink MUL to MULS.</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
MULS adversely affects performance on many implementations. Where this
is the case, we prefer not to shrink MUL to MULS.</pre>
</div>
</content>
</entry>
<entry>
<title>[CodeGen] Make the parameter TRI required in some functions. (#85968)</title>
<updated>2024-04-24T13:24:14+00:00</updated>
<author>
<name>Xu Zhang</name>
<email>simonzgx@gmail.com</email>
</author>
<published>2024-04-24T13:24:14+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=f6d431f208c0fa48827eac40e7acf788346a9967'/>
<id>f6d431f208c0fa48827eac40e7acf788346a9967</id>
<content type='text'>
Fixes #82659

There are some functions, such as `findRegisterDefOperandIdx` and  `findRegisterDefOperand`, that have too many default parameters. As a result, we have encountered some issues due to the lack of TRI  parameters, as shown in issue #82411.

Following @RKSimon 's suggestion, this patch refactors 9 functions, including `{reads, kills, defines, modifies}Register`,  `registerDefIsDead`, and `findRegister{UseOperandIdx, UseOperand, DefOperandIdx, DefOperand}`, adjusting the order of the TRI parameter and making it required. In addition, all the places that call these functions have also been updated correctly to ensure no additional impact.

After this, the caller of these functions should explicitly know whether to pass the `TargetRegisterInfo` or just a `nullptr`.</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Fixes #82659

There are some functions, such as `findRegisterDefOperandIdx` and  `findRegisterDefOperand`, that have too many default parameters. As a result, we have encountered some issues due to the lack of TRI  parameters, as shown in issue #82411.

Following @RKSimon 's suggestion, this patch refactors 9 functions, including `{reads, kills, defines, modifies}Register`,  `registerDefIsDead`, and `findRegister{UseOperandIdx, UseOperand, DefOperandIdx, DefOperand}`, adjusting the order of the TRI parameter and making it required. In addition, all the places that call these functions have also been updated correctly to ensure no additional impact.

After this, the caller of these functions should explicitly know whether to pass the `TargetRegisterInfo` or just a `nullptr`.</pre>
</div>
</content>
</entry>
<entry>
<title>[MC] Define and use MCInstrDesc implicit_uses and implicit_defs. NFC.</title>
<updated>2023-01-23T14:44:58+00:00</updated>
<author>
<name>Jay Foad</name>
<email>jay.foad@amd.com</email>
</author>
<published>2023-01-11T12:20:02+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=073401e59c8c0e03e06be1d516fe8ea821146d2f'/>
<id>073401e59c8c0e03e06be1d516fe8ea821146d2f</id>
<content type='text'>
The new methods return a range for easier iteration. Use them everywhere
instead of getImplicitUses, getNumImplicitUses, getImplicitDefs and
getNumImplicitDefs. A future patch will remove the old methods.

In some use cases the new methods are less efficient because they always
have to scan the whole uses/defs array to count its length, but that
will be fixed in a future patch by storing the number of implicit
uses/defs explicitly in MCInstrDesc. At that point there will be no need
to 0-terminate the arrays.

Differential Revision: https://reviews.llvm.org/D142215
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
The new methods return a range for easier iteration. Use them everywhere
instead of getImplicitUses, getNumImplicitUses, getImplicitDefs and
getNumImplicitDefs. A future patch will remove the old methods.

In some use cases the new methods are less efficient because they always
have to scan the whole uses/defs array to count its length, but that
will be fixed in a future patch by storing the number of implicit
uses/defs explicitly in MCInstrDesc. At that point there will be no need
to 0-terminate the arrays.

Differential Revision: https://reviews.llvm.org/D142215
</pre>
</div>
</content>
</entry>
<entry>
<title>[MC] Make more use of MCInstrDesc::operands. NFC.</title>
<updated>2023-01-23T11:31:41+00:00</updated>
<author>
<name>Jay Foad</name>
<email>jay.foad@amd.com</email>
</author>
<published>2023-01-13T13:56:47+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=768aed13785b6a42cc3bcfe829efc231ba536909'/>
<id>768aed13785b6a42cc3bcfe829efc231ba536909</id>
<content type='text'>
Change MCInstrDesc::operands to return an ArrayRef so we can easily use
it everywhere instead of the (IMHO ugly) opInfo_begin and opInfo_end.
A future patch will remove opInfo_begin and opInfo_end.

Also use it instead of raw access to the OpInfo pointer. A future patch
will remove this pointer.

Differential Revision: https://reviews.llvm.org/D142213
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Change MCInstrDesc::operands to return an ArrayRef so we can easily use
it everywhere instead of the (IMHO ugly) opInfo_begin and opInfo_end.
A future patch will remove opInfo_begin and opInfo_end.

Also use it instead of raw access to the OpInfo pointer. A future patch
will remove this pointer.

Differential Revision: https://reviews.llvm.org/D142213
</pre>
</div>
</content>
</entry>
<entry>
<title>[llvm] Use std::size instead of llvm::array_lengthof</title>
<updated>2022-09-08T15:01:53+00:00</updated>
<author>
<name>Joe Loser</name>
<email>joeloser@fastmail.com</email>
</author>
<published>2022-09-07T00:06:58+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=5e96cea1db0623a833d5376c9ea2ce4528771f97'/>
<id>5e96cea1db0623a833d5376c9ea2ce4528771f97</id>
<content type='text'>
LLVM contains a helpful function for getting the size of a C-style
array: `llvm::array_lengthof`. This is useful prior to C++17, but not as
helpful for C++17 or later: `std::size` already has support for C-style
arrays.

Change call sites to use `std::size` instead.

Differential Revision: https://reviews.llvm.org/D133429
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
LLVM contains a helpful function for getting the size of a C-style
array: `llvm::array_lengthof`. This is useful prior to C++17, but not as
helpful for C++17 or later: `std::size` already has support for C-style
arrays.

Change call sites to use `std::size` instead.

Differential Revision: https://reviews.llvm.org/D133429
</pre>
</div>
</content>
</entry>
<entry>
<title>[llvm] LLVM_FALLTHROUGH =&gt; [[fallthrough]]. NFC</title>
<updated>2022-08-08T18:24:15+00:00</updated>
<author>
<name>Fangrui Song</name>
<email>i@maskray.me</email>
</author>
<published>2022-08-08T18:24:15+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=de9d80c1c579e39cc658a508f1d4ba1cd792e4d5'/>
<id>de9d80c1c579e39cc658a508f1d4ba1cd792e4d5</id>
<content type='text'>
With C++17 there is no Clang pedantic warning or MSVC C5051.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
With C++17 there is no Clang pedantic warning or MSVC C5051.
</pre>
</div>
</content>
</entry>
<entry>
<title>[ARM] Use llvm::dbgs() to print debug info (NFC)</title>
<updated>2022-06-06T20:43:16+00:00</updated>
<author>
<name>ksyx</name>
<email>18738953+ksyx@users.noreply.github.com</email>
</author>
<published>2022-06-06T20:39:28+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=3204272f0f1ac64a62357620210d565de17739d7'/>
<id>3204272f0f1ac64a62357620210d565de17739d7</id>
<content type='text'>
For consistency with other parts of code.

Approved by efriedma in differential revision
https://reviews.llvm.org/D127055
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
For consistency with other parts of code.

Approved by efriedma in differential revision
https://reviews.llvm.org/D127055
</pre>
</div>
</content>
</entry>
<entry>
<title>[ARM] Add SEH opcodes in frame lowering</title>
<updated>2022-06-02T09:28:46+00:00</updated>
<author>
<name>Martin Storsjö</name>
<email>martin@martin.st</email>
</author>
<published>2021-11-26T12:28:16+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=d8e67c1cccd8fcb62230166caea744592288da17'/>
<id>d8e67c1cccd8fcb62230166caea744592288da17</id>
<content type='text'>
Skip inserting regular CFI instructions if using WinCFI.

This is based a fair amount on the corresponding ARM64 implementation,
but instead of trying to insert the SEH opcodes one by one where
we generate other prolog/epilog instructions, we try to walk over the
whole prolog/epilog range and insert them. This is done because in
many cases, the exact number of instructions inserted is abstracted
away deeper.

For some cases, we manually insert specific SEH opcodes directly where
instructions are generated, where the automatic mapping of instructions
to SEH opcodes doesn't hold up (e.g. for __chkstk stack probes).

Skip Thumb2SizeReduction for SEH prologs/epilogs, and force
tail calls to wide instructions (just like on MachO), to make sure
that the unwind info actually matches the width of the final
instructions, without heuristics about what later passes will do.

Mark SEH instructions as scheduling boundaries, to make sure that they
aren't reordered away from the instruction they describe by
PostRAScheduler.

Mark the SEH instructions with the NoMerge flag, to avoid doing
tail merging of functions that have multiple epilogs that all end
with the same sequence of "b &lt;other&gt;; .seh_nop_w, .seh_endepilogue".

Differential Revision: https://reviews.llvm.org/D125648
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Skip inserting regular CFI instructions if using WinCFI.

This is based a fair amount on the corresponding ARM64 implementation,
but instead of trying to insert the SEH opcodes one by one where
we generate other prolog/epilog instructions, we try to walk over the
whole prolog/epilog range and insert them. This is done because in
many cases, the exact number of instructions inserted is abstracted
away deeper.

For some cases, we manually insert specific SEH opcodes directly where
instructions are generated, where the automatic mapping of instructions
to SEH opcodes doesn't hold up (e.g. for __chkstk stack probes).

Skip Thumb2SizeReduction for SEH prologs/epilogs, and force
tail calls to wide instructions (just like on MachO), to make sure
that the unwind info actually matches the width of the final
instructions, without heuristics about what later passes will do.

Mark SEH instructions as scheduling boundaries, to make sure that they
aren't reordered away from the instruction they describe by
PostRAScheduler.

Mark the SEH instructions with the NoMerge flag, to avoid doing
tail merging of functions that have multiple epilogs that all end
with the same sequence of "b &lt;other&gt;; .seh_nop_w, .seh_endepilogue".

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