<feed xmlns='http://www.w3.org/2005/Atom'>
<title>llvm-project.git/llvm/lib/Target/Mips/MipsSEInstrInfo.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>[CodeGen] Change copyPhysReg interface to use Register instead of MCRegister. (#128473)</title>
<updated>2025-02-24T17:55:34+00:00</updated>
<author>
<name>Craig Topper</name>
<email>craig.topper@sifive.com</email>
</author>
<published>2025-02-24T17:55:34+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=571b787b83cb1bfc7d4c8214b296ec965e7bb7e2'/>
<id>571b787b83cb1bfc7d4c8214b296ec965e7bb7e2</id>
<content type='text'>
NVPTX, SPIRV, and WebAssembly pass virtual registers to this function
since they don't perform register allocation. We need to use Register to
avoid a virtual register being converted to MCRegister by the caller.</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
NVPTX, SPIRV, and WebAssembly pass virtual registers to this function
since they don't perform register allocation. We need to use Register to
avoid a virtual register being converted to MCRegister by the caller.</pre>
</div>
</content>
</entry>
<entry>
<title>[llvm] Pass MachineInstr flags to storeRegToStackSlot/loadRegFromStackSlot (NFC) (#120622)</title>
<updated>2025-01-22T08:06:39+00:00</updated>
<author>
<name>Venkata Ramanaiah Nalamothu</name>
<email>quic_vnalamot@quicinc.com</email>
</author>
<published>2025-01-22T08:06:39+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=f7d8336a2fb4fad4a6efe5af9b0a10ddd970f6d3'/>
<id>f7d8336a2fb4fad4a6efe5af9b0a10ddd970f6d3</id>
<content type='text'>
This patch is in preparation to enable setting the MachineInstr::MIFlag
flags, i.e. FrameSetup/FrameDestroy, on callee saved register
spill/reload instructions in prologue/epilogue. This eventually helps in
setting the prologue_end and epilogue_begin markers more accurately.

The DWARF Spec in "6.4 Call Frame Information" says:

The code that allocates space on the call frame stack and performs the
save
operation is called the subroutine’s prologue, and the code that
performs
the restore operation and deallocates the frame is called its epilogue.

which means the callee saved register spills and reloads are part of
prologue (a.k.a frame setup) and epilogue (a.k.a frame destruction),
respectively. And, IIUC, LLVM backend uses FrameSetup/FrameDestroy flags
to identify instructions that are part of call frame setup and
destruction.

In the trunk, while most targets consistently set
FrameSetup/FrameDestroy on save/restore call frame information (CFI)
instructions of callee saved registers, they do not consistently set
those flags on the actual callee saved register spill/reload
instructions.

I believe this patch provides a clean mechanism to set
FrameSetup/FrameDestroy flags on the actual callee saved register
spill/reload instructions as needed. And, by having default argument of
MachineInstr::NoFlags for Flags, this patch is a NFC.

With this patch, the targets have to just pass FrameSetup/FrameDestroy
flag to the storeRegToStackSlot/loadRegFromStackSlot calls from the
target derived spillCalleeSavedRegisters and restoreCalleeSavedRegisters
to set those flags on callee saved register spill/reload instructions.

Also, this patch makes it very easy to set the source line information
on callee saved register spill/reload instructions which is needed by
the DwarfDebug.cpp implementation to set prologue_end and epilogue_begin
markers more accurately.

As per DwarfDebug.cpp implementation:

prologue_end is the first known non-DBG_VALUE and non-FrameSetup
location
    that marks the beginning of the function body

epilogue_begin is the first FrameDestroy location that has been seen in
the
    epilogue basic block

With this patch, the targets have to just do the following to set the
source line information on callee saved register spill/reload
instructions, without hampering the LLVM's efforts to avoid adding
source line information on the artificial code generated by the
compiler.

    &lt;Foo&gt;InstrInfo::storeRegToStackSlot() {
    ...
      DebugLoc DL =
Flags &amp; MachineInstr::FrameSetup ? DebugLoc() : MBB.findDebugLoc(I);
    ...
    }

    &lt;Foo&gt;InstrInfo::loadRegFromStackSlot() {
    ...
      DebugLoc DL =
Flags &amp; MachineInstr::FrameDestroy ? MBB.findDebugLoc(I) : DebugLoc();
    ...
    }

While I understand this patch would break out-of-tree backend builds, I
think it is in the right direction.

One immediate use case that can benefit from this patch is fixing
#120553 becomes simpler.</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This patch is in preparation to enable setting the MachineInstr::MIFlag
flags, i.e. FrameSetup/FrameDestroy, on callee saved register
spill/reload instructions in prologue/epilogue. This eventually helps in
setting the prologue_end and epilogue_begin markers more accurately.

The DWARF Spec in "6.4 Call Frame Information" says:

The code that allocates space on the call frame stack and performs the
save
operation is called the subroutine’s prologue, and the code that
performs
the restore operation and deallocates the frame is called its epilogue.

which means the callee saved register spills and reloads are part of
prologue (a.k.a frame setup) and epilogue (a.k.a frame destruction),
respectively. And, IIUC, LLVM backend uses FrameSetup/FrameDestroy flags
to identify instructions that are part of call frame setup and
destruction.

In the trunk, while most targets consistently set
FrameSetup/FrameDestroy on save/restore call frame information (CFI)
instructions of callee saved registers, they do not consistently set
those flags on the actual callee saved register spill/reload
instructions.

I believe this patch provides a clean mechanism to set
FrameSetup/FrameDestroy flags on the actual callee saved register
spill/reload instructions as needed. And, by having default argument of
MachineInstr::NoFlags for Flags, this patch is a NFC.

With this patch, the targets have to just pass FrameSetup/FrameDestroy
flag to the storeRegToStackSlot/loadRegFromStackSlot calls from the
target derived spillCalleeSavedRegisters and restoreCalleeSavedRegisters
to set those flags on callee saved register spill/reload instructions.

Also, this patch makes it very easy to set the source line information
on callee saved register spill/reload instructions which is needed by
the DwarfDebug.cpp implementation to set prologue_end and epilogue_begin
markers more accurately.

As per DwarfDebug.cpp implementation:

prologue_end is the first known non-DBG_VALUE and non-FrameSetup
location
    that marks the beginning of the function body

epilogue_begin is the first FrameDestroy location that has been seen in
the
    epilogue basic block

With this patch, the targets have to just do the following to set the
source line information on callee saved register spill/reload
instructions, without hampering the LLVM's efforts to avoid adding
source line information on the artificial code generated by the
compiler.

    &lt;Foo&gt;InstrInfo::storeRegToStackSlot() {
    ...
      DebugLoc DL =
Flags &amp; MachineInstr::FrameSetup ? DebugLoc() : MBB.findDebugLoc(I);
    ...
    }

    &lt;Foo&gt;InstrInfo::loadRegFromStackSlot() {
    ...
      DebugLoc DL =
Flags &amp; MachineInstr::FrameDestroy ? MBB.findDebugLoc(I) : DebugLoc();
    ...
    }

While I understand this patch would break out-of-tree backend builds, I
think it is in the right direction.

One immediate use case that can benefit from this patch is fixing
#120553 becomes simpler.</pre>
</div>
</content>
</entry>
<entry>
<title>[Mips] Remove unused includes (NFC) (#116499)</title>
<updated>2024-11-16T20:13:26+00:00</updated>
<author>
<name>Kazu Hirata</name>
<email>kazu@google.com</email>
</author>
<published>2024-11-16T20:13:26+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=73e89cf66d4b88d568ff4c718ae7bf55588ef2be'/>
<id>73e89cf66d4b88d568ff4c718ae7bf55588ef2be</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>[TII][RISCV] Add renamable bit to copyPhysReg (#91179)</title>
<updated>2024-08-27T02:08:43+00:00</updated>
<author>
<name>Piyou Chen</name>
<email>piyou.chen@sifive.com</email>
</author>
<published>2024-08-27T02:08:43+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=b01c006f734a0977a4fd9c7f1a706c8230663739'/>
<id>b01c006f734a0977a4fd9c7f1a706c8230663739</id>
<content type='text'>
The renamable flag is useful during MachineCopyPropagation but renamable
flag will be dropped after lowerCopy in some case.

This patch introduces extra arguments to pass the renamable flag to
copyPhysReg.</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
The renamable flag is useful during MachineCopyPropagation but renamable
flag will be dropped after lowerCopy in some case.

This patch introduces extra arguments to pass the renamable flag to
copyPhysReg.</pre>
</div>
</content>
</entry>
<entry>
<title>[TTI] Use Register in isLoadFromStackSlot and isStoreToStackSlot [nfc] (#80339)</title>
<updated>2024-02-02T01:52:35+00:00</updated>
<author>
<name>Philip Reames</name>
<email>preames@rivosinc.com</email>
</author>
<published>2024-02-02T01:52:35+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=3ff7caea330def5f8433e3eb2b89ae3fe5e9f9a0'/>
<id>3ff7caea330def5f8433e3eb2b89ae3fe5e9f9a0</id>
<content type='text'>
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
</pre>
</div>
</content>
</entry>
<entry>
<title>[Mips] Remove isMoveReg=1 from wrdsp and rddsp instructions</title>
<updated>2023-07-03T15:49:09+00:00</updated>
<author>
<name>Yashwant Singh</name>
<email>Yashwant.Singh@amd.com</email>
</author>
<published>2023-07-03T15:23:05+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=0f58cfeb9fff4f0490a798d65038fd43c5178c2c'/>
<id>0f58cfeb9fff4f0490a798d65038fd43c5178c2c</id>
<content type='text'>
This is a prep patch for D150388. Treating rddsp and wrdsp as copy
instructions was causing test failures as we tried using isCopyInstr()
hook to query target-specific copy instructions for LiveRangeSplitting.

As suggested, removing 'isMoveReg = 1' from wrdsp and rddsp so they
aren't considered simple copy-like instructions for the moment.

Reviewed By: sdardis

Differential Revision: https://reviews.llvm.org/D151181
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This is a prep patch for D150388. Treating rddsp and wrdsp as copy
instructions was causing test failures as we tried using isCopyInstr()
hook to query target-specific copy instructions for LiveRangeSplitting.

As suggested, removing 'isMoveReg = 1' from wrdsp and rddsp so they
aren't considered simple copy-like instructions for the moment.

Reviewed By: sdardis

Differential Revision: https://reviews.llvm.org/D151181
</pre>
</div>
</content>
</entry>
<entry>
<title>[Target] llvm::Optional =&gt; std::optional</title>
<updated>2022-12-04T22:43:14+00:00</updated>
<author>
<name>Fangrui Song</name>
<email>i@maskray.me</email>
</author>
<published>2022-12-04T22:43:14+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=b0df70403d20e8aad5eb1abe147441d8763f333b'/>
<id>b0df70403d20e8aad5eb1abe147441d8763f333b</id>
<content type='text'>
The updated functions are mostly internal with a few exceptions (virtual functions in
TargetInstrInfo.h, TargetRegisterInfo.h).
To minimize changes to LLVMCodeGen, GlobalISel files are skipped.

https://discourse.llvm.org/t/deprecating-llvm-optional-x-hasvalue-getvalue-getvalueor/63716
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
The updated functions are mostly internal with a few exceptions (virtual functions in
TargetInstrInfo.h, TargetRegisterInfo.h).
To minimize changes to LLVMCodeGen, GlobalISel files are skipped.

https://discourse.llvm.org/t/deprecating-llvm-optional-x-hasvalue-getvalue-getvalueor/63716
</pre>
</div>
</content>
</entry>
<entry>
<title>[Target] Use std::nullopt instead of None (NFC)</title>
<updated>2022-12-03T04:36:06+00:00</updated>
<author>
<name>Kazu Hirata</name>
<email>kazu@google.com</email>
</author>
<published>2022-12-03T04:36:06+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=20cde15415d2b2d1b489b4cd5c520c6a8d7f8f54'/>
<id>20cde15415d2b2d1b489b4cd5c520c6a8d7f8f54</id>
<content type='text'>
This patch mechanically replaces None with std::nullopt where the
compiler would warn if None were deprecated.  The intent is to reduce
the amount of manual work required in migrating from Optional to
std::optional.

This is part of an effort to migrate from llvm::Optional to
std::optional:

https://discourse.llvm.org/t/deprecating-llvm-optional-x-hasvalue-getvalue-getvalueor/63716
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This patch mechanically replaces None with std::nullopt where the
compiler would warn if None were deprecated.  The intent is to reduce
the amount of manual work required in migrating from Optional to
std::optional.

This is part of an effort to migrate from llvm::Optional to
std::optional:

https://discourse.llvm.org/t/deprecating-llvm-optional-x-hasvalue-getvalue-getvalueor/63716
</pre>
</div>
</content>
</entry>
<entry>
<title>Move TargetRegistry.(h|cpp) from Support to MC</title>
<updated>2021-10-08T21:51:48+00:00</updated>
<author>
<name>Reid Kleckner</name>
<email>rnk@google.com</email>
</author>
<published>2021-10-08T17:48:15+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=89b57061f7b769e9ea9bf6ed686e284f3e55affe'/>
<id>89b57061f7b769e9ea9bf6ed686e284f3e55affe</id>
<content type='text'>
This moves the registry higher in the LLVM library dependency stack.
Every client of the target registry needs to link against MC anyway to
actually use the target, so we might as well move this out of Support.

This allows us to ensure that Support doesn't have includes from MC/*.

Differential Revision: https://reviews.llvm.org/D111454
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This moves the registry higher in the LLVM library dependency stack.
Every client of the target registry needs to link against MC anyway to
actually use the target, so we might as well move this out of Support.

This allows us to ensure that Support doesn't have includes from MC/*.

Differential Revision: https://reviews.llvm.org/D111454
</pre>
</div>
</content>
</entry>
<entry>
<title>[Mips] Make MipsBranchExpansion aware of BBIT family of branch</title>
<updated>2020-03-31T07:20:51+00:00</updated>
<author>
<name>Djordje Todorovic</name>
<email>djordje.todorovic@syrmia.com</email>
</author>
<published>2020-03-27T08:11:48+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=bcbd60aeb5fe20136fe79270ac1b8f3936883d78'/>
<id>bcbd60aeb5fe20136fe79270ac1b8f3936883d78</id>
<content type='text'>
Octeon branches (bbit0/bbit032/bbit1/bbit132) have an immediate operand,
so it is legal to have such replacement within
MipsBranchExpansion::replaceBranch().

According to the specification, a branch (e.g. bbit0 ) looks like:

bbit0  rs p offset  // p is an immediate operand
  if !rs&lt;p&gt; then branch

Without this patch, an assertion triggers in the method,
and the problem has been found in the real example.

Differential Revision: https://reviews.llvm.org/D76842
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Octeon branches (bbit0/bbit032/bbit1/bbit132) have an immediate operand,
so it is legal to have such replacement within
MipsBranchExpansion::replaceBranch().

According to the specification, a branch (e.g. bbit0 ) looks like:

bbit0  rs p offset  // p is an immediate operand
  if !rs&lt;p&gt; then branch

Without this patch, an assertion triggers in the method,
and the problem has been found in the real example.

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