<feed xmlns='http://www.w3.org/2005/Atom'>
<title>llvm-project.git/llvm/lib/CodeGen/GlobalISel/MachineIRBuilder.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>Reland [llvm] Add support for llvm IR atomicrmw fminimum/fmaximum instructions (#137701)</title>
<updated>2025-04-30T21:06:37+00:00</updated>
<author>
<name>Jonathan Thackray</name>
<email>jonathan.thackray@arm.com</email>
</author>
<published>2025-04-30T21:06:37+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=6e49f73825f1b9cb98352a7c8dca3e0cf83ebd9e'/>
<id>6e49f73825f1b9cb98352a7c8dca3e0cf83ebd9e</id>
<content type='text'>
This patch adds support for LLVM IR atomicrmw `fmaximum` and `fminimum`
instructions.

These mirror the `llvm.maximum.*` and `llvm.minimum.*` instructions, but
are atomic and use IEEE754 2019 handling for NaNs, which is different to
`fmax` and `fmin`. See:
     https://llvm.org/docs/LangRef.html#llvm-minimum-intrinsic
for more details.

Future changes will allow this LLVM IR to be lowered to specialised
assembler instructions on suitable targets, such as AArch64.</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This patch adds support for LLVM IR atomicrmw `fmaximum` and `fminimum`
instructions.

These mirror the `llvm.maximum.*` and `llvm.minimum.*` instructions, but
are atomic and use IEEE754 2019 handling for NaNs, which is different to
`fmax` and `fmin`. See:
     https://llvm.org/docs/LangRef.html#llvm-minimum-intrinsic
for more details.

Future changes will allow this LLVM IR to be lowered to specialised
assembler instructions on suitable targets, such as AArch64.</pre>
</div>
</content>
</entry>
<entry>
<title>Revert "[llvm] Add support for llvm IR atomicrmw fminimum/fmaximum instructions" (#137657)</title>
<updated>2025-04-28T15:53:36+00:00</updated>
<author>
<name>Jonathan Thackray</name>
<email>jonathan.thackray@arm.com</email>
</author>
<published>2025-04-28T15:53:36+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=7ee0097b486b31be8b9a1750b2cd47580efd9587'/>
<id>7ee0097b486b31be8b9a1750b2cd47580efd9587</id>
<content type='text'>
Reverts llvm/llvm-project#136759 due to bad interaction with c792b25e4</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Reverts llvm/llvm-project#136759 due to bad interaction with c792b25e4</pre>
</div>
</content>
</entry>
<entry>
<title>[llvm] Add support for llvm IR atomicrmw fminimum/fmaximum instructions (#136759)</title>
<updated>2025-04-28T14:31:44+00:00</updated>
<author>
<name>Jonathan Thackray</name>
<email>jonathan.thackray@arm.com</email>
</author>
<published>2025-04-28T14:31:44+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=ba420d8122239592a1fb7ad6efd2c186aecfdef5'/>
<id>ba420d8122239592a1fb7ad6efd2c186aecfdef5</id>
<content type='text'>
This patch adds support for LLVM IR atomicrmw `fmaximum` and `fminimum`
instructions.

These mirror the `llvm.maximum.*` and `llvm.minimum.*` instructions, but
are atomic and use IEEE754 2019 handling for NaNs, which is different to
`fmax` and `fmin`. See:
     https://llvm.org/docs/LangRef.html#llvm-minimum-intrinsic
for more details.

Future changes will allow this LLVM IR to be lowered to specialised
assembler instructions on suitable targets, such as AArch64.</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This patch adds support for LLVM IR atomicrmw `fmaximum` and `fminimum`
instructions.

These mirror the `llvm.maximum.*` and `llvm.minimum.*` instructions, but
are atomic and use IEEE754 2019 handling for NaNs, which is different to
`fmax` and `fmin`. See:
     https://llvm.org/docs/LangRef.html#llvm-minimum-intrinsic
for more details.

Future changes will allow this LLVM IR to be lowered to specialised
assembler instructions on suitable targets, such as AArch64.</pre>
</div>
</content>
</entry>
<entry>
<title>[LLVM][GlobalISel] Ensure G_{F}CONSTANT only store references to scalar Constant{Int,FP}. (#137319)</title>
<updated>2025-04-28T10:40:39+00:00</updated>
<author>
<name>Paul Walker</name>
<email>paul.walker@arm.com</email>
</author>
<published>2025-04-28T10:40:39+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=be82be281d92091af98f2d27f2a8dad7bc160a62'/>
<id>be82be281d92091af98f2d27f2a8dad7bc160a62</id>
<content type='text'>
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
</pre>
</div>
</content>
</entry>
<entry>
<title>[Intrinsics] Add Intrinsic::getFnAttributes() (NFC) (#132029)</title>
<updated>2025-03-20T08:20:39+00:00</updated>
<author>
<name>Nikita Popov</name>
<email>npopov@redhat.com</email>
</author>
<published>2025-03-20T08:20:39+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=0738f706151b41063d09b2dc349cabd471b2476e'/>
<id>0738f706151b41063d09b2dc349cabd471b2476e</id>
<content type='text'>
Most places that call Intrinsic::getAttributes() are only interested in
the function attributes, so add a separate function for that.

The motivation for this is that I'd like to add the ability to specify
range attributes on intrinsics, which requires knowing the function
type. This avoids needing to know the type for most attribute queries.</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Most places that call Intrinsic::getAttributes() are only interested in
the function attributes, so add a separate function for that.

The motivation for this is that I'd like to add the ability to specify
range attributes on intrinsics, which requires knowing the function
type. This avoids needing to know the type for most attribute queries.</pre>
</div>
</content>
</entry>
<entry>
<title>[GlobalISel] Use Register. NFC</title>
<updated>2025-03-03T07:46:18+00:00</updated>
<author>
<name>Craig Topper</name>
<email>craig.topper@sifive.com</email>
</author>
<published>2025-03-03T07:02:13+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=caa798cb1e5cc8d4d75ed2347e3f2df533367c25'/>
<id>caa798cb1e5cc8d4d75ed2347e3f2df533367c25</id>
<content type='text'>
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
</pre>
</div>
</content>
</entry>
<entry>
<title>AMDGPU/GlobalISel: AMDGPURegBankLegalize (#112864)</title>
<updated>2025-01-24T11:12:45+00:00</updated>
<author>
<name>Petar Avramovic</name>
<email>Petar.Avramovic@amd.com</email>
</author>
<published>2025-01-24T11:12:45+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=0ee037b861f94604907d95d0ff0ff87805b52428'/>
<id>0ee037b861f94604907d95d0ff0ff87805b52428</id>
<content type='text'>
Lower G_ instructions that can't be inst-selected with register bank
assignment from AMDGPURegBankSelect based on uniformity analysis.
- Lower instruction to perform it on assigned register bank
- Put uniform value in vgpr because SALU instruction is not available
- Execute divergent instruction in SALU - "waterfall loop"

Given LLTs on all operands after legalizer, some register bank
assignments require lowering while other do not.
Note: cases where all register bank assignments would require lowering
are lowered in legalizer.

AMDGPURegBankLegalize goals:
- Define Rules: when and how to perform lowering
- Goal of defining Rules it to provide high level table-like brief
  overview of how to lower generic instructions based on available
  target features and uniformity info (uniform vs divergent).
- Fast search of Rules, depends on how complicated Rule.Predicate is
- For some opcodes there would be too many Rules that are essentially
  all the same just for different combinations of types and banks.
  Write custom function that handles all cases.
- Rules are made from enum IDs that correspond to each operand.
  Names of IDs are meant to give brief description what lowering does
  for each operand or the whole instruction.
- AMDGPURegBankLegalizeHelper implements lowering algorithms

Since this is the first patch that actually enables -new-reg-bank-select
here is the summary of regression tests that were added earlier:
- if instruction is uniform always select SALU instruction if available
- eliminate back to back vgpr to sgpr to vgpr copies of uniform values
- fast rules: small differences for standard and vector instruction
- enabling Rule based on target feature - salu_float
- how to specify lowering algorithm - vgpr S64 AND to S32
- on G_TRUNC in reg, it is up to user to deal with truncated bits
  G_TRUNC in reg is treated as no-op.
- dealing with truncated high bits - ABS S16 to S32
- sgpr S1 phi lowering
- new opcodes for vcc-to-scc and scc-to-vcc copies
- lowering for vgprS1-to-vcc copy (formally this is vgpr-to-vcc G_TRUNC)
- S1 zext and sext lowering to select
- uniform and divergent S1 AND(OR and XOR) lowering - inst-selected into
  SALU instruction
- divergent phi with uniform inputs
- divergent instruction with temporal divergent use, source instruction
  is defined as uniform(AMDGPURegBankSelect) - missing temporal
  divergence lowering
- uniform phi, because of undef incoming, is assigned to vgpr. Will be
  fixed in AMDGPURegBankSelect via another fix in machine uniformity
  analysis.</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Lower G_ instructions that can't be inst-selected with register bank
assignment from AMDGPURegBankSelect based on uniformity analysis.
- Lower instruction to perform it on assigned register bank
- Put uniform value in vgpr because SALU instruction is not available
- Execute divergent instruction in SALU - "waterfall loop"

Given LLTs on all operands after legalizer, some register bank
assignments require lowering while other do not.
Note: cases where all register bank assignments would require lowering
are lowered in legalizer.

AMDGPURegBankLegalize goals:
- Define Rules: when and how to perform lowering
- Goal of defining Rules it to provide high level table-like brief
  overview of how to lower generic instructions based on available
  target features and uniformity info (uniform vs divergent).
- Fast search of Rules, depends on how complicated Rule.Predicate is
- For some opcodes there would be too many Rules that are essentially
  all the same just for different combinations of types and banks.
  Write custom function that handles all cases.
- Rules are made from enum IDs that correspond to each operand.
  Names of IDs are meant to give brief description what lowering does
  for each operand or the whole instruction.
- AMDGPURegBankLegalizeHelper implements lowering algorithms

Since this is the first patch that actually enables -new-reg-bank-select
here is the summary of regression tests that were added earlier:
- if instruction is uniform always select SALU instruction if available
- eliminate back to back vgpr to sgpr to vgpr copies of uniform values
- fast rules: small differences for standard and vector instruction
- enabling Rule based on target feature - salu_float
- how to specify lowering algorithm - vgpr S64 AND to S32
- on G_TRUNC in reg, it is up to user to deal with truncated bits
  G_TRUNC in reg is treated as no-op.
- dealing with truncated high bits - ABS S16 to S32
- sgpr S1 phi lowering
- new opcodes for vcc-to-scc and scc-to-vcc copies
- lowering for vgprS1-to-vcc copy (formally this is vgpr-to-vcc G_TRUNC)
- S1 zext and sext lowering to select
- uniform and divergent S1 AND(OR and XOR) lowering - inst-selected into
  SALU instruction
- divergent phi with uniform inputs
- divergent instruction with temporal divergent use, source instruction
  is defined as uniform(AMDGPURegBankSelect) - missing temporal
  divergence lowering
- uniform phi, because of undef incoming, is assigned to vgpr. Will be
  fixed in AMDGPURegBankSelect via another fix in machine uniformity
  analysis.</pre>
</div>
</content>
</entry>
<entry>
<title>[AArch64][GlobalISel] Legalize ptr shuffle vector to s64 (#116013)</title>
<updated>2024-11-23T17:00:51+00:00</updated>
<author>
<name>David Green</name>
<email>david.green@arm.com</email>
</author>
<published>2024-11-23T17:00:51+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=d3ce069572cb565da613df9828ac54f7edb2fc00'/>
<id>d3ce069572cb565da613df9828ac54f7edb2fc00</id>
<content type='text'>
This converts all ptr element shuffle vectors to s64, so that the
existing vector legalization handling can lower them as needed. This
prevents a lot of fallbacks that currently try to generate things like
`&lt;2 x ptr&gt; G_EXT`.

I'm not sure if bitcast/inttoptr/ptrtoint is intended to be necessary
for vectors of pointers, but it uses buildCast for the casts, which now
generates a ptrtoint/inttoptr.</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This converts all ptr element shuffle vectors to s64, so that the
existing vector legalization handling can lower them as needed. This
prevents a lot of fallbacks that currently try to generate things like
`&lt;2 x ptr&gt; G_EXT`.

I'm not sure if bitcast/inttoptr/ptrtoint is intended to be necessary
for vectors of pointers, but it uses buildCast for the casts, which now
generates a ptrtoint/inttoptr.</pre>
</div>
</content>
</entry>
<entry>
<title>[GlobalISel] Import llvm.stepvector (#115721)</title>
<updated>2024-11-11T20:35:22+00:00</updated>
<author>
<name>Thorsten Schütt</name>
<email>schuett@gmail.com</email>
</author>
<published>2024-11-11T20:35:22+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=e399322d5ef2919ccd12f28a00e6b24621b11072'/>
<id>e399322d5ef2919ccd12f28a00e6b24621b11072</id>
<content type='text'>
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
</pre>
</div>
</content>
</entry>
<entry>
<title>[GlobalISel] Add G_STEP_VECTOR instruction (#115598)</title>
<updated>2024-11-11T09:45:02+00:00</updated>
<author>
<name>Thorsten Schütt</name>
<email>schuett@gmail.com</email>
</author>
<published>2024-11-11T09:45:02+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=a5d09f4ad94fab718e787fb6dce7933e7742eb1b'/>
<id>a5d09f4ad94fab718e787fb6dce7933e7742eb1b</id>
<content type='text'>
aka llvm.stepvector Intrinsic</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
aka llvm.stepvector Intrinsic</pre>
</div>
</content>
</entry>
</feed>
