llvm-project.git/llvm/test/CodeGen/X86/bitreverse.ll, branch users/nico/python-2 Unnamed repository; edit this file 'description' to name the repository. [X86] ReplaceNodeResults - adjust assert to allow XOP or GFNI subtargets to split i64 BITREVERSE nodes on 32-bit targets 2024-10-24T13:39:07+00:00 Simon Pilgrim llvm-dev@redking.me.uk 2024-10-23T14:53:07+00:00 b34d64921b2f878b6e1ac7205fc4b13d54a7d8db Fixes #113353 Fixes #113034 
Fixes #113353
Fixes #113034
[X86] getGFNICtrlMask - create a vXi8 mask instead of a bitcasted vXi64 mask. 2024-07-18T14:15:38+00:00 Simon Pilgrim llvm-dev@redking.me.uk 2024-07-18T14:09:40+00:00 92f9f014015554c5dd18df4699765cc42853a04d Helps avoid some missed load-folds by stripping away bitcasts and make it easier to grok the GF2P8AFFINEQB masks. 
Helps avoid some missed load-folds by stripping away bitcasts and make it easier to grok the GF2P8AFFINEQB masks.
Support for i8/i16 for bitreverse using GFNI. (#88625) 2024-04-15T09:38:26+00:00 shamithoke 152091883+shamithoke@users.noreply.github.com 2024-04-15T09:38:26+00:00 c7bd284dc3ff21a5a14b4ccbbfa1988de8723c33 In continuation to the PR #81764, this change extends the GFNI support to i8 and i16. --------- Co-authored-by: shami <shami_thoke@yahoo.com> 
In continuation to the PR #81764, this change extends the GFNI support to i8 and i16.

---------

Co-authored-by: shami <shami_thoke@yahoo.com>
 Perform bitreverse using AVX512 GFNI for i32 and i64. (#81764) 2024-04-10T19:22:44+00:00 shamithoke 152091883+shamithoke@users.noreply.github.com 2024-04-10T19:22:44+00:00 e3ef4612c18845876cda9a13c3435e102f74a3aa Currently, the lowering operation for bitreverse using Intel AVX512 GFNI only supports byte vectors Extend the operation to i32 and i64. --------- Co-authored-by: shami <shami_thoke@yahoo.com> 
Currently, the lowering operation for bitreverse using Intel AVX512 GFNI only supports byte vectors

Extend the operation to i32 and i64.

---------

Co-authored-by: shami <shami_thoke@yahoo.com>
 [X86] X86FixupVectorConstants - shrink vector load to movsd/movsd/movd/movq 'zero upper' instructions (#79000) 2024-01-24T14:00:51+00:00 Simon Pilgrim RKSimon@users.noreply.github.com 2024-01-24T14:00:51+00:00 8b43c1be23119c1024bed0a8ce392bc73727e2e2 If we're loading a vector constant that is known to be zero in the upper elements, then attempt to shrink the constant and just scalar load the lower 32/64 bits. Always chose the vzload/broadcast with the smallest constant load, and prefer vzload over broadcasts for same bitwidth to avoid domain flips (mainly a AVX1 issue). Fixes #73783 
If we're loading a vector constant that is known to be zero in the upper elements, then attempt to shrink the constant and just scalar load the lower 32/64 bits.

Always chose the vzload/broadcast with the smallest constant load, and prefer vzload over broadcasts for same bitwidth to avoid domain flips (mainly a AVX1 issue).

Fixes #73783
 [MC][X86] Merge lane/element broadcast comment printers. (#79020) 2024-01-23T12:33:52+00:00 Simon Pilgrim RKSimon@users.noreply.github.com 2024-01-23T12:33:52+00:00 4318b033bddc64d5654f3e368fddde859ff4d02e This is /almost/ NFC - the only annoyance is that for some reason we were using "<C1,C2,..>" for ConstantVector types unlike all other cases - these now use the same "[C1,C2,..]" format as the other constant printers. 
This is /almost/ NFC - the only annoyance is that for some reason we were using "<C1,C2,..>" for ConstantVector types unlike all other cases - these now use the same "[C1,C2,..]" format as the other constant printers.
 Revert "[CodeGen] Really renumber slot indexes before register allocation (#67038)" 2023-10-09T11:31:32+00:00 Jay Foad jay.foad@amd.com 2023-10-09T11:31:32+00:00 7b3bbd83c0c24087072ec5b22a76799ab31f87d5 This reverts commit 2501ae58e3bb9a70d279a56d7b3a0ed70a8a852c. Reverted due to various buildbot failures. 
This reverts commit 2501ae58e3bb9a70d279a56d7b3a0ed70a8a852c.

Reverted due to various buildbot failures.
[CodeGen] Really renumber slot indexes before register allocation (#67038) 2023-10-09T10:44:41+00:00 Jay Foad jay.foad@amd.com 2023-10-09T10:44:41+00:00 2501ae58e3bb9a70d279a56d7b3a0ed70a8a852c PR #66334 tried to renumber slot indexes before register allocation, but the numbering was still affected by list entries for instructions which had been erased. Fix this to make the register allocator's live range length heuristics even less dependent on the history of how instructions have been added to and removed from SlotIndexes's maps. 
PR #66334 tried to renumber slot indexes before register allocation, but
the numbering was still affected by list entries for instructions which
had been erased. Fix this to make the register allocator's live range
length heuristics even less dependent on the history of how instructions
have been added to and removed from SlotIndexes's maps.
 [CodeGen] Renumber slot indexes before register allocation (#66334) 2023-09-19T10:18:12+00:00 Jay Foad jay.foad@amd.com 2023-09-13T19:22:45+00:00 e0919b189bf2df4f97f22ba40260ab5153988b14 RegAllocGreedy uses SlotIndexes::getApproxInstrDistance to approximate the length of a live range for its heuristics. Renumbering all slot indexes with the default instruction distance ensures that this estimate will be as accurate as possible, and will not depend on the history of how instructions have been added to and removed from SlotIndexes's maps. This also means that enabling -early-live-intervals, which runs the SlotIndexes analysis earlier, will not cause large amounts of churn due to different register allocator decisions. 
RegAllocGreedy uses SlotIndexes::getApproxInstrDistance to approximate
the length of a live range for its heuristics. Renumbering all slot
indexes with the default instruction distance ensures that this estimate
will be as accurate as possible, and will not depend on the history of
how instructions have been added to and removed from SlotIndexes's maps.

This also means that enabling -early-live-intervals, which runs the
SlotIndexes analysis earlier, will not cause large amounts of churn due
to different register allocator decisions.
[X86] X86FixupVectorConstantsPass - attempt to replace full width fp vector constant loads with broadcasts on AVX+ targets (REAPPLIED) 2023-06-13T11:10:11+00:00 Simon Pilgrim llvm-dev@redking.me.uk 2023-06-13T10:55:41+00:00 834cc88c5d08ca55664b7742590463de813d768f lowerBuildVectorAsBroadcast will not broadcast splat constants in all cases, resulting in a lot of situations where a full width vector load that has failed to fold but is loading splat constant values could use a broadcast load instruction just as cheaply, and save constant pool space. NOTE: SSE3 targets can use MOVDDUP but not all SSE era CPUs can perform this as cheaply as a vector load, we will need to add scheduler model checks if we want to pursue this. This is an updated commit of 98061013e01207444cfd3980cde17b5e75764fbe after being reverted at a279a09ab9524d1d74ef29b34618102d4b202e2f 
lowerBuildVectorAsBroadcast will not broadcast splat constants in all cases, resulting in a lot of situations where a full width vector load that has failed to fold but is loading splat constant values could use a broadcast load instruction just as cheaply, and save constant pool space.

NOTE: SSE3 targets can use MOVDDUP but not all SSE era CPUs can perform this as cheaply as a vector load, we will need to add scheduler model checks if we want to pursue this.

This is an updated commit of 98061013e01207444cfd3980cde17b5e75764fbe after being reverted at a279a09ab9524d1d74ef29b34618102d4b202e2f