Changes in fabs.f64.ll

3eb2281b - [AMDGPU] Aggressively fold immediates in SIFoldOperands

Mon, 16 May 2022 14:48:11 +0000

[AMDGPU] Aggressively fold immediates in SIFoldOperandsPreviously SIFoldOperands::foldInstOperand would only fold anon-inlinable immediate into a single user, so as not to increase codesize by adding the same 32-bit literal operand to many instructions.This patch removes that restriction, so that a non-inlinable immediatewill be folded into any number of users. The rationale is:- It reduces the number of registers used for holding constant values, which might increase occupancy. (On the other hand, many of these registers are SGPRs which no longer affect occupancy on GFX10+.)- It reduces ALU stalls between the instruction that loads a constant into a register, and the instruction that uses it.- The above benefits are expected to outweigh any increase in code size.Differential Revision: https://reviews.llvm.org/D114643 List of files: /llvm-project-15.0.7/llvm/test/CodeGen/AMDGPU/fabs.f64.ll

9e03e8c9 - [AMDGPU] Enable fneg and fabs divergence-driven instruction selection.

Fri, 19 Nov 2021 17:27:35 +0000

[AMDGPU] Enable fneg and fabs divergence-driven instruction selection.Detailed description: We currently have a set of patterns to select ISD::FNEG and ISD::FABS to the bitwise operations. We need to make them predicated to select the VALU or SALU bitwise operation variant according to the SDNode divergence bit.Reviewed By: rampitecDifferential Revision: https://reviews.llvm.org/D114257 List of files: /llvm-project-15.0.7/llvm/test/CodeGen/AMDGPU/fabs.f64.ll

8c4a3523 - AMDGPU: Add pass to lower kernel arguments to loads

Tue, 26 Jun 2018 19:10:00 +0000

AMDGPU: Add pass to lower kernel arguments to loadsThis replaces most argument uses with loads, but fornow not all.The code in SelectionDAG for calling convention loweringis actively harmful for amdgpu_kernel. It attempts tosplit the argument types into register legal types, whichresults in low quality code for arbitary types. Sinceall kernel arguments are passed in memory, we just want theraw types.I've tried a couple of methods of mitigating this in SelectionDAG,but it's easier to just bypass this problem alltogether. It'spossible to hack around the problem in the initial lowering,but the real problem is the DAG then expects to be able to useCopyToReg/CopyFromReg for uses of the arguments outside the block.Exposing the argument loads in the IR also has the advantagethat the LoadStoreVectorizer can merge them.I'm not sure the best approach to dealing with the IRargument list is. The patch as-is just leaves the IR argumentsin place, so all the existing code will still compute the samekernarg size and pointlessly lowers the arguments.Arguably the frontend should emit kernels with an empty argumentlist in the first place. Alternatively a dummy array could beinserted as a single argument just to reserve space.This does have some disadvantages. Local pointer kernel arguments canno longer have AssertZext placed on them as the equivalent !rangemetadata is not valid on pointer typed loads. This is mostly badfor SI which needs to know about the known bits in order to use theDS instruction offset, so in this case this is not done.More importantly, this skips noalias arguments since this passdoes not yet convert this to the equivalent !alias.scope and !noaliasmetadata. Producing this metadata correctly seems to be tricky,although this logically is the same as inlining into a function whichdoesn't exist. Additionally, exposing these loads to the vectorizermay result in degraded aliasing information if a pointer load ismerged with another argument load.I'm also not entirely sure this is preserving the current cloverABI, although I would greatly prefer if it would stop wideningarguments and match the HSA ABI. As-is I think it is extending< 4-byte arguments to 4-bytes but doesn't align them to 4-bytes.llvm-svn: 335650 List of files: /llvm-project-15.0.7/llvm/test/CodeGen/AMDGPU/fabs.f64.ll

56ea488d - [AMDGPU] Allow SDWA in instructions with immediates and SGPRs

Tue, 30 May 2017 16:49:24 +0000

[AMDGPU] Allow SDWA in instructions with immediates and SGPRsAn encoding does not allow to use SDWA in an instruction withscalar operands, either literals or SGPRs. That is however possibleto copy these operands into a VGPR first.Several copies of the value are produced if multiple SDWA conversionswere done. To cleanup MachineLICM (to hoist copies out of loops),MachineCSE (to remove duplicate copies) and SIFoldOperands (to replaceSGPR to VGPR copy with immediate copy right to the VGPR) runs are addedafter the SDWA pass.Differential Revision: https://reviews.llvm.org/D33583llvm-svn: 304219 List of files: /llvm-project-15.0.7/llvm/test/CodeGen/AMDGPU/fabs.f64.ll

3dbeefa9 - AMDGPU: Mark all unspecified CC functions in tests as amdgpu_kernel

Tue, 21 Mar 2017 21:39:51 +0000

AMDGPU: Mark all unspecified CC functions in tests as amdgpu_kernelCurrently the default C calling convention functions are treatedthe same as compute kernels. Make this explicit so the defaultcalling convention can be changed to a non-kernel.Converted with perl -pi -e 's/define void/define amdgpu_kernel void/'on the relevant test directories (and undoing in one place that actuallywanted a non-kernel).llvm-svn: 298444 List of files: /llvm-project-15.0.7/llvm/test/CodeGen/AMDGPU/fabs.f64.ll

bbb47da8 - AMDGPU: Support commuting with immediate in src0

Thu, 08 Sep 2016 17:19:29 +0000

AMDGPU: Support commuting with immediate in src0llvm-svn: 280970 List of files: /llvm-project-15.0.7/llvm/test/CodeGen/AMDGPU/fabs.f64.ll

9c47dd58 - AMDGPU: Remove some old intrinsic uses from tests

Thu, 11 Feb 2016 06:02:01 +0000

AMDGPU: Remove some old intrinsic uses from testsllvm-svn: 260493 List of files: /llvm-project-15.0.7/llvm/test/CodeGen/AMDGPU/fabs.f64.ll

45bb48ea - R600 -> AMDGPU rename

Sat, 13 Jun 2015 03:28:10 +0000

R600 -> AMDGPU renamellvm-svn: 239657 List of files: /llvm-project-15.0.7/llvm/test/CodeGen/AMDGPU/fabs.f64.ll