<feed xmlns='http://www.w3.org/2005/Atom'>
<title>llvm-project.git/llvm/lib/CodeGen/CFIInstrInserter.cpp, branch users/fmayer/spr/main.compiler-rt-tsan-leave-bufferedstacktrace-uninit</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>Spill/restore FP/BP around instructions in which they are clobbered (#81048)</title>
<updated>2024-08-06T23:18:20+00:00</updated>
<author>
<name>weiguozhi</name>
<email>57237827+weiguozhi@users.noreply.github.com</email>
</author>
<published>2024-08-06T23:18:20+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=0d471b3f64d3116bd57c79d872f7384fff80daa5'/>
<id>0d471b3f64d3116bd57c79d872f7384fff80daa5</id>
<content type='text'>
This patch fixes https://github.com/llvm/llvm-project/issues/17204.

If a base pointer is used in a function, and it is clobbered by an
instruction (typically an inline asm), current register allocator can't
handle this situation, so BP becomes garbage after those instructions.
It can also occur to FP in theory.

We can spill and reload FP/BP registers around those instructions. But
normal spill/reload instructions also use FP/BP, so we can't spill them
into normal spill slots, instead we spill them into the top of stack by
using SP register.</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This patch fixes https://github.com/llvm/llvm-project/issues/17204.

If a base pointer is used in a function, and it is clobbered by an
instruction (typically an inline asm), current register allocator can't
handle this situation, so BP becomes garbage after those instructions.
It can also occur to FP in theory.

We can spill and reload FP/BP registers around those instructions. But
normal spill/reload instructions also use FP/BP, so we can't spill them
into normal spill slots, instead we spill them into the top of stack by
using SP register.</pre>
</div>
</content>
</entry>
<entry>
<title>[LLVM] [MC] Update frame layout &amp; CFI generation to handle frames larger than 2gb (#99263)</title>
<updated>2024-07-23T16:43:30+00:00</updated>
<author>
<name>Wesley Wiser</name>
<email>wwiser@gmail.com</email>
</author>
<published>2024-07-23T16:43:30+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=ca076f7a63f6a80e2e38315ec462be354b196b8d'/>
<id>ca076f7a63f6a80e2e38315ec462be354b196b8d</id>
<content type='text'>
Rebase of #84114. I've only included the core changes to frame layout
calculation &amp; CFI generation which sidesteps the regressions found after
merging #84114. Since these changes are a necessary precursor to the
overall fix and are themselves slightly beneficial as CFI is now
generated correctly, I think it is reasonable to merge this first step.

---

For very large stack frames, the offset from the stack pointer to a
local can be more than 2^31 which overflows various `int` offsets in the
frame lowering code.

This patch updates the frame lowering code to calculate the offsets as
64-bit values and fixes CFI to use the corrected sizes.

After this patch, additional work is needed to fix offset truncations in
each target's codegen.</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Rebase of #84114. I've only included the core changes to frame layout
calculation &amp; CFI generation which sidesteps the regressions found after
merging #84114. Since these changes are a necessary precursor to the
overall fix and are themselves slightly beneficial as CFI is now
generated correctly, I think it is reasonable to merge this first step.

---

For very large stack frames, the offset from the stack pointer to a
local can be more than 2^31 which overflows various `int` offsets in the
frame lowering code.

This patch updates the frame lowering code to calculate the offsets as
64-bit values and fixes CFI to use the corrected sizes.

After this patch, additional work is needed to fix offset truncations in
each target's codegen.</pre>
</div>
</content>
</entry>
<entry>
<title>[MC] Support .cfi_label</title>
<updated>2024-07-07T19:41:13+00:00</updated>
<author>
<name>Fangrui Song</name>
<email>i@maskray.me</email>
</author>
<published>2024-07-07T19:41:13+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=2718654c542c742e2dd18dcda8b93de1d4d3b640'/>
<id>2718654c542c742e2dd18dcda8b93de1d4d3b640</id>
<content type='text'>
GNU assembler 2.26 introduced the .cfi_label directive. It does not
expand to any CFI instructions, but defines a label in
.eh_frame/.debug_frame, which can be used by runtime patching code to
locate the FDE. .cfi_label is not allowed for CIE's initial
instructions, and can therefore be used to force the next instruction to
be placed in a FDE instead of a CIE.

In glibc since 2018, sysdeps/riscv/start.S utilizes .cfi_label to force
DW_CFA_undefined to be placed in a FDE. arc/csky/loongarch ports have
copied this use.
```
.cfi_startproc
// DW_CFA_undefined is allowed for CIE's initial instructions.
// Without .cfi_label, gas would place DW_CFA_undefined in a CIE.
.cfi_label .Ldummy
.cfi_undefined ra
.cfi_endproc
```

No CFI instruction is associated with .cfi_label, so the `case
MCCFIInstruction::OpLabel:` code in BOLT is unreachable and onlt to make
-Wswitch happy.

Close #97222

Pull Request: https://github.com/llvm/llvm-project/pull/97922
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
GNU assembler 2.26 introduced the .cfi_label directive. It does not
expand to any CFI instructions, but defines a label in
.eh_frame/.debug_frame, which can be used by runtime patching code to
locate the FDE. .cfi_label is not allowed for CIE's initial
instructions, and can therefore be used to force the next instruction to
be placed in a FDE instead of a CIE.

In glibc since 2018, sysdeps/riscv/start.S utilizes .cfi_label to force
DW_CFA_undefined to be placed in a FDE. arc/csky/loongarch ports have
copied this use.
```
.cfi_startproc
// DW_CFA_undefined is allowed for CIE's initial instructions.
// Without .cfi_label, gas would place DW_CFA_undefined in a CIE.
.cfi_label .Ldummy
.cfi_undefined ra
.cfi_endproc
```

No CFI instruction is associated with .cfi_label, so the `case
MCCFIInstruction::OpLabel:` code in BOLT is unreachable and onlt to make
-Wswitch happy.

Close #97222

Pull Request: https://github.com/llvm/llvm-project/pull/97922
</pre>
</div>
</content>
</entry>
<entry>
<title>Revert rG58de1e2c5eee548a9b365e3b1554d87317072ad9 "Fix stack layout for frames larger than 2gb (#84114)"</title>
<updated>2024-03-27T16:16:15+00:00</updated>
<author>
<name>Simon Pilgrim</name>
<email>llvm-dev@redking.me.uk</email>
</author>
<published>2024-03-27T16:16:15+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=78f0871beed002187e65cc1334087596e9c11043'/>
<id>78f0871beed002187e65cc1334087596e9c11043</id>
<content type='text'>
This is failing on some EXPENSIVE_CHECKS buildbots
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This is failing on some EXPENSIVE_CHECKS buildbots
</pre>
</div>
</content>
</entry>
<entry>
<title>Fix stack layout for frames larger than 2gb (#84114)</title>
<updated>2024-03-27T15:05:58+00:00</updated>
<author>
<name>Wesley Wiser</name>
<email>wwiser@gmail.com</email>
</author>
<published>2024-03-27T15:05:58+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=58de1e2c5eee548a9b365e3b1554d87317072ad9'/>
<id>58de1e2c5eee548a9b365e3b1554d87317072ad9</id>
<content type='text'>
For very large stack frames, the offset from the stack pointer to a local can be more than 2^31 which overflows various `int` offsets in the frame lowering code.

This patch updates the frame lowering code to calculate the offsets as 64-bit values and resolves the overflows, resulting in the correct codegen for very large frames.

Fixes #48911</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
For very large stack frames, the offset from the stack pointer to a local can be more than 2^31 which overflows various `int` offsets in the frame lowering code.

This patch updates the frame lowering code to calculate the offsets as 64-bit values and resolves the overflows, resulting in the correct codegen for very large frames.

Fixes #48911</pre>
</div>
</content>
</entry>
<entry>
<title>[CFIInstrInserter] Use number of supported registers (NFC) (#71797)</title>
<updated>2023-11-09T13:43:45+00:00</updated>
<author>
<name>Nikita Popov</name>
<email>npopov@redhat.com</email>
</author>
<published>2023-11-09T13:43:45+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=f67158422c3bf37ce3884f4579a93f65e083e7fa'/>
<id>f67158422c3bf37ce3884f4579a93f65e083e7fa</id>
<content type='text'>
This makes use of the more accurate register number introduced in PR
#70222 to avoid CFI calculations for unsupported registers.

This has basically no impact right now, but results in a 0.2% compile-time
improvement at O0 when applied on top of #70958.

The reason is that the extra registers that PR adds push the `BitVector`
out of the `SmallVector` space, which results in an outsized impact.
(This does make me wonder whether `BitVector` should accept an `N`
template parameter to allow using a larger `SmallVector`...)</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This makes use of the more accurate register number introduced in PR
#70222 to avoid CFI calculations for unsupported registers.

This has basically no impact right now, but results in a 0.2% compile-time
improvement at O0 when applied on top of #70958.

The reason is that the extra registers that PR adds push the `BitVector`
out of the `SmallVector` space, which results in an outsized impact.
(This does make me wonder whether `BitVector` should accept an `N`
template parameter to allow using a larger `SmallVector`...)</pre>
</div>
</content>
</entry>
<entry>
<title>[X86] Use the CFA when appropriate for better variable locations around calls.</title>
<updated>2023-05-23T20:24:55+00:00</updated>
<author>
<name>Kyle Huey</name>
<email>khuey@pernos.co</email>
</author>
<published>2023-05-23T17:44:25+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=3be667ae5a10e276acf7d1bb7e8c29ba07578032'/>
<id>3be667ae5a10e276acf7d1bb7e8c29ba07578032</id>
<content type='text'>
Without frame pointers, the locations of variables on the stack are emitted
relative to the stack pointer (via the stack pointer being the value of
DW_AT_frame_base on the subprogram). If a call modifies the stack pointer
this results in the locations being wrong and the debugger displaying the
wrong values for variables.

By using DW_OP_call_frame_cfa in these situations the emitted location for
the variable will automatically handle changes in the stack pointer
(provided LLVM is emitting the correct CFI directives elsewhere, of course).
The CFA needs to be adjusted for the size of the stack frame (including the
return address) to allow the variable locations themselves to remain
unchanged by this patch.

Certain LLDB features cannot cope with DW_OP_call_frame_cfa, so this change
is heuristically limited to the cases where it's necessary for correctness
to minimize the fallout there.

Reviewed By: #debug-info, scott.linder, jryans, jmorse

Differential Revision: https://reviews.llvm.org/D143463
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Without frame pointers, the locations of variables on the stack are emitted
relative to the stack pointer (via the stack pointer being the value of
DW_AT_frame_base on the subprogram). If a call modifies the stack pointer
this results in the locations being wrong and the debugger displaying the
wrong values for variables.

By using DW_OP_call_frame_cfa in these situations the emitted location for
the variable will automatically handle changes in the stack pointer
(provided LLVM is emitting the correct CFI directives elsewhere, of course).
The CFA needs to be adjusted for the size of the stack frame (including the
return address) to allow the variable locations themselves to remain
unchanged by this patch.

Certain LLDB features cannot cope with DW_OP_call_frame_cfa, so this change
is heuristically limited to the cases where it's necessary for correctness
to minimize the fallout there.

Reviewed By: #debug-info, scott.linder, jryans, jmorse

Differential Revision: https://reviews.llvm.org/D143463
</pre>
</div>
</content>
</entry>
<entry>
<title>[CodeGen] llvm::Optional =&gt; std::optional</title>
<updated>2022-12-13T09:06:36+00:00</updated>
<author>
<name>Fangrui Song</name>
<email>i@maskray.me</email>
</author>
<published>2022-12-13T09:06:36+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=67819a72c6ba39267effe8edfc1befddc3f3f2f9'/>
<id>67819a72c6ba39267effe8edfc1befddc3f3f2f9</id>
<content type='text'>
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
</pre>
</div>
</content>
</entry>
<entry>
<title>[NFC] Use Register instead of unsigned for variables that receive a Register object</title>
<updated>2022-12-07T00:23:34+00:00</updated>
<author>
<name>Gregory Alfonso</name>
<email>gfunni234@gmail.com</email>
</author>
<published>2022-12-07T00:23:34+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=cb38be9ed3af2331fb340916e178d3bff52030bc'/>
<id>cb38be9ed3af2331fb340916e178d3bff52030bc</id>
<content type='text'>
Reviewed By: MaskRay

Differential Revision: https://reviews.llvm.org/D139451
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Reviewed By: MaskRay

Differential Revision: https://reviews.llvm.org/D139451
</pre>
</div>
</content>
</entry>
<entry>
<title>Cleanup codegen includes</title>
<updated>2022-03-16T07:43:00+00:00</updated>
<author>
<name>serge-sans-paille</name>
<email>sguelton@redhat.com</email>
</author>
<published>2022-03-15T09:54:19+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=989f1c72e0f4236ac35a35cc9998ea34bc62d5cd'/>
<id>989f1c72e0f4236ac35a35cc9998ea34bc62d5cd</id>
<content type='text'>
This is a (fixed) recommit of https://reviews.llvm.org/D121169

after:  1061034926
before: 1063332844

Discourse thread: https://discourse.llvm.org/t/include-what-you-use-include-cleanup
Differential Revision: https://reviews.llvm.org/D121681
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This is a (fixed) recommit of https://reviews.llvm.org/D121169

after:  1061034926
before: 1063332844

Discourse thread: https://discourse.llvm.org/t/include-what-you-use-include-cleanup
Differential Revision: https://reviews.llvm.org/D121681
</pre>
</div>
</content>
</entry>
</feed>
