[PATCH] D133850: [AArch64] Improve codegen for "trunc <4 x i64> to <4 x i8>" for all cases

Sheng via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Sun Sep 25 15:44:52 PDT 2022


0x59616e updated this revision to Diff 462775.
0x59616e added a comment.

bitcast is handled in this diff.

To handle bitcast, we need this observation: `uzp1` is just a `xtn` that operates on two register simultaneously.

For example, given the following register v0 with type `v2i64`:

 __________________

| _x0__x1_ | _x2__x3_ |
|

Applying `xtn` on it we get:
 ____  ____

| _x0_ | _x2_ |
|

This is equivalent to bitcast it to `v4i32`, and then applying `uzp1` on it:
 ___________________                             _____________________________________

| _x0_ | _x1_ | _x2_ | _x3_ | ===uzp1===> | _x0_ | _x2_ | <value from other register> |
|

We can transform `xtn` to `uzp1` by this observation, and vice versa.

This observation only works on little endian target. Big endian target has a problem: the `uzp1` cannot be replaced by `xtn` since there is a discrepancy in the behavior of `uzp1` between the little endian and big endian. To illustrate, take the following for example:

LSB                       MSB

 ___________________

| _x0_ | _x1_ | _x2_ | _x3_ |
|

On little endian, `uzp1` grabs `x0` and `x2`, which is right; on big endian, it grabs `x3` and `x1`, which doesn't match what I saw on the document. But, since I'm new to AArch64, take my word with a pinch of salt. Maybe there's issue in the order of the value printed by gdb ?

I disable this on big endian target temporarily until we find the crux.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D133850/new/

https://reviews.llvm.org/D133850

Files:
  llvm/lib/Target/AArch64/AArch64ISelLowering.cpp
  llvm/test/CodeGen/AArch64/aarch64-uzp1-combine.ll

-------------- next part --------------
A non-text attachment was scrubbed...
Name: D133850.462775.patch
Type: text/x-patch
Size: 6067 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20220925/9a2317be/attachment.bin>


More information about the llvm-commits mailing list