<feed xmlns='http://www.w3.org/2005/Atom'>
<title>llvm-project.git, branch users/jofrn/fix-amdgpu-cs-chain-frame-pointer</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>Rename indirect to recurse and keep in original file -- invalid for gfx1200. Move fp_all test to fp-nosave since it compiles on both gfx942 and gfx1200.</title>
<updated>2025-11-10T15:51:05+00:00</updated>
<author>
<name>jofrn</name>
<email>jofernau@amd.com</email>
</author>
<published>2025-11-10T15:51:05+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=506b411d359500e1f54388723d97b3fac80ac740'/>
<id>506b411d359500e1f54388723d97b3fac80ac740</id>
<content type='text'>
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
</pre>
</div>
</content>
</entry>
<entry>
<title>Added test case to verify no FP setup occurs with "frame-pointer"="all".</title>
<updated>2025-11-10T13:07:55+00:00</updated>
<author>
<name>jofrn</name>
<email>jofernau@amd.com</email>
</author>
<published>2025-11-10T13:07:55+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=820b9c3b03403a2f2f3b931648c9923cefdf8ff7'/>
<id>820b9c3b03403a2f2f3b931648c9923cefdf8ff7</id>
<content type='text'>
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
</pre>
</div>
</content>
</entry>
<entry>
<title>For emitEpilogue, emitCSRSpillRestores' argument in FPSaved case to handle chain functions in same way as non-FPSaved case, an offset. Remove prior hardcode to s33 and do not restore FP for chain functions.</title>
<updated>2025-11-10T12:19:12+00:00</updated>
<author>
<name>jofrn</name>
<email>jofernau@amd.com</email>
</author>
<published>2025-11-10T11:11:59+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=d4eecd03899caa1217f1f894eaee9cf9a15bed47'/>
<id>d4eecd03899caa1217f1f894eaee9cf9a15bed47</id>
<content type='text'>
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
</pre>
</div>
</content>
</entry>
<entry>
<title>[AMDGPU] Initialize FrameOffsetReg for amdgpu_cs_chain functions</title>
<updated>2025-11-10T12:19:11+00:00</updated>
<author>
<name>jofrn</name>
<email>jofernau@amd.com</email>
</author>
<published>2025-10-29T06:51:36+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=4c9ae7c657210e7875bfcda4f96cdd6ffd93613c'/>
<id>4c9ae7c657210e7875bfcda4f96cdd6ffd93613c</id>
<content type='text'>
Functions with the amdgpu_cs_chain calling convention were not
initializing FrameOffsetReg, leaving it as FP_REG.
This caused machine code verification failures
as SCRATCH_STORE_DWORD_SADDR instructions require the saddr
operand to be in the SReg_32_XEXEC_HI register class.

This LLVM defect was identified via the AMD Fuzzing project.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Functions with the amdgpu_cs_chain calling convention were not
initializing FrameOffsetReg, leaving it as FP_REG.
This caused machine code verification failures
as SCRATCH_STORE_DWORD_SADDR instructions require the saddr
operand to be in the SReg_32_XEXEC_HI register class.

This LLVM defect was identified via the AMD Fuzzing project.
</pre>
</div>
</content>
</entry>
<entry>
<title>[tools][llc] Make save-stats.ll test target independent (#167238)</title>
<updated>2025-11-10T11:51:07+00:00</updated>
<author>
<name>Tomer Shafir</name>
<email>tomer.shafir8@gmail.com</email>
</author>
<published>2025-11-10T11:51:07+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=b18d828eeae03cc9c42edf4d72911c75f117397c'/>
<id>b18d828eeae03cc9c42edf4d72911c75f117397c</id>
<content type='text'>
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
</pre>
</div>
</content>
</entry>
<entry>
<title>[AArch64] Fallback to PRFUM for PRFM with negative or unaligned offset (#166756)</title>
<updated>2025-11-10T11:11:51+00:00</updated>
<author>
<name>Cullen Rhodes</name>
<email>cullen.rhodes@arm.com</email>
</author>
<published>2025-11-10T11:11:51+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=54d86df4a22c226a957e87375b91db478c641d60'/>
<id>54d86df4a22c226a957e87375b91db478c641d60</id>
<content type='text'>
Section C3.2.2 (quoted below) in the ARMARM makes this a requirement of
assemblers for load/stores with unscaled offset. It makes no mention of
PRFM so I don't consider this to be a bug, although I can see why we
would want to extend this behaviour to the unscaled variants of these
instructions as well, as GCC does. This patch adds an alias for this.

C3.2.2 Load/store register (unscaled offset)

  The load/store register instructions with an unscaled offset support
  only one addressing mode:

      Base plus an unscaled 9-bit signed immediate offset.

  See Load/store addressing modes.

  The load/store register (unscaled offset) instructions are required to
  disambiguate this instruction class from the load/store register
instruction forms that support an addressing mode of base plus a scaled,
unsigned 12-bit immediate offset, because that can represent some offset
  values in the same range.

  The ambiguous immediate offsets are byte offsets that are both:

      In the range 0-255, inclusive.

      Naturally aligned to the access size.

  Other byte offsets in the range -256 to 255 inclusive are unambiguous.
  An assembler program translating a load/store instruction, for example
  LDR, is required to encode an unambiguous offset using the unscaled
  9-bit offset form, and to encode an ambiguous offset using the scaled
  12-bit offset form. A programmer might force the generation of the
  unscaled 9-bit form by using one of the mnemonics in Table C.3.21. Arm
  recommends that a disassembler outputs all unscaled 9-bit offset forms
  using one of these mnemonics, but unambiguous offsets can be output
  using a load/store single register mnemonic, for example, LDR.

Fixes #83226.</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Section C3.2.2 (quoted below) in the ARMARM makes this a requirement of
assemblers for load/stores with unscaled offset. It makes no mention of
PRFM so I don't consider this to be a bug, although I can see why we
would want to extend this behaviour to the unscaled variants of these
instructions as well, as GCC does. This patch adds an alias for this.

C3.2.2 Load/store register (unscaled offset)

  The load/store register instructions with an unscaled offset support
  only one addressing mode:

      Base plus an unscaled 9-bit signed immediate offset.

  See Load/store addressing modes.

  The load/store register (unscaled offset) instructions are required to
  disambiguate this instruction class from the load/store register
instruction forms that support an addressing mode of base plus a scaled,
unsigned 12-bit immediate offset, because that can represent some offset
  values in the same range.

  The ambiguous immediate offsets are byte offsets that are both:

      In the range 0-255, inclusive.

      Naturally aligned to the access size.

  Other byte offsets in the range -256 to 255 inclusive are unambiguous.
  An assembler program translating a load/store instruction, for example
  LDR, is required to encode an unambiguous offset using the unscaled
  9-bit offset form, and to encode an ambiguous offset using the scaled
  12-bit offset form. A programmer might force the generation of the
  unscaled 9-bit form by using one of the mnemonics in Table C.3.21. Arm
  recommends that a disassembler outputs all unscaled 9-bit offset forms
  using one of these mnemonics, but unambiguous offsets can be output
  using a load/store single register mnemonic, for example, LDR.

Fixes #83226.</pre>
</div>
</content>
</entry>
<entry>
<title>[X86] ldexp-avx512.ll - add v8f16/v16f16/v32f16 test coverage for #165694 (#167294)</title>
<updated>2025-11-10T10:57:29+00:00</updated>
<author>
<name>Simon Pilgrim</name>
<email>llvm-dev@redking.me.uk</email>
</author>
<published>2025-11-10T10:57:29+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=0e6c8daabb76fe40e4e60e7e82a907648412e3cd'/>
<id>0e6c8daabb76fe40e4e60e7e82a907648412e3cd</id>
<content type='text'>
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
</pre>
</div>
</content>
</entry>
<entry>
<title>[DropAssumes] Drop dereferenceable assumptions after vectorization. (#166947)</title>
<updated>2025-11-10T10:50:15+00:00</updated>
<author>
<name>Florian Hahn</name>
<email>flo@fhahn.com</email>
</author>
<published>2025-11-10T10:50:15+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=80fa6e1bcea054109a154916e37ccfe7b9b0a9fb'/>
<id>80fa6e1bcea054109a154916e37ccfe7b9b0a9fb</id>
<content type='text'>
This patch adds another run of DropUnnecessaryAssumes after
vectorization, to clean up assumes that are not longer needed after this
point.

The main example of such an assume is currently dereferenceable
assumptions. This complements
https://github.com/llvm/llvm-project/pull/166945, which avoids sinking
code if it would mean remove a dereferenceable assumption.

There are a few additional cases where some unneeded assumes are left
over after vectorization that also get cleaned up.

The main motivation is to work together with
https://github.com/llvm/llvm-project/pull/166945, but there may be a
better solution.

Adding another instance of this pass to the pipeline is not great, but
compile-time impact seems in the noise:
https://llvm-compile-time-tracker.com/compare.php?from=55e71fe08b6406ec7ce2c81ce042e48717acf204&amp;to=85da4ee3a74126f557cdc74c7b40e048dacb3fc4&amp;stat=instructions:u

PR: https://github.com/llvm/llvm-project/pull/166947</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This patch adds another run of DropUnnecessaryAssumes after
vectorization, to clean up assumes that are not longer needed after this
point.

The main example of such an assume is currently dereferenceable
assumptions. This complements
https://github.com/llvm/llvm-project/pull/166945, which avoids sinking
code if it would mean remove a dereferenceable assumption.

There are a few additional cases where some unneeded assumes are left
over after vectorization that also get cleaned up.

The main motivation is to work together with
https://github.com/llvm/llvm-project/pull/166945, but there may be a
better solution.

Adding another instance of this pass to the pipeline is not great, but
compile-time impact seems in the noise:
https://llvm-compile-time-tracker.com/compare.php?from=55e71fe08b6406ec7ce2c81ce042e48717acf204&amp;to=85da4ee3a74126f557cdc74c7b40e048dacb3fc4&amp;stat=instructions:u

PR: https://github.com/llvm/llvm-project/pull/166947</pre>
</div>
</content>
</entry>
<entry>
<title>[VPlan] Simplify branch-cond with getVectorTripCount (#155604)</title>
<updated>2025-11-10T10:43:37+00:00</updated>
<author>
<name>Ramkumar Ramachandra</name>
<email>ramkumar.ramachandra@codasip.com</email>
</author>
<published>2025-11-10T10:43:37+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=2d1d5fe78ed01810c89f3705acfe93a7e219c08f'/>
<id>2d1d5fe78ed01810c89f3705acfe93a7e219c08f</id>
<content type='text'>
Call getVectorTripCount first, and call getTripCount failing that, in
simplifyBranchConditionForVFAndUF, to simplify missed cases. While at
it, strip the dead check for a zero TC.</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Call getVectorTripCount first, and call getTripCount failing that, in
simplifyBranchConditionForVFAndUF, to simplify missed cases. While at
it, strip the dead check for a zero TC.</pre>
</div>
</content>
</entry>
<entry>
<title>Remove unused &lt;algorithm&gt; inclusion (#166942)</title>
<updated>2025-11-10T10:30:37+00:00</updated>
<author>
<name>serge-sans-paille</name>
<email>sguelton@mozilla.com</email>
</author>
<published>2025-11-10T10:30:37+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=898d6fecf6636521321af17fcd69a19f30fa8cf8'/>
<id>898d6fecf6636521321af17fcd69a19f30fa8cf8</id>
<content type='text'>
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
</pre>
</div>
</content>
</entry>
</feed>
