[PATCH] D156396: [AArch64] Respect pre-/post-decrement indexing mode during instruction selection

[Maurice Heumann via Phabricator via llvm-commits]

momo5502 added a comment.

Here's a bit more context:

I have a sample, which, unfortunately, I am not able to disclose. In one basicblock, the following transformation is made in SelectionDAG:

F28464341: image.png <https://reviews.llvm.org/F28464341>

What's essentially happening here is that the following expression:

  t54 = t53 - 8
  load(t54)

is transformed to:

`load<pre-dec>(t53, 8)`. Due to the pre-dec indexing mode, this should mean this: `load(t53 - 8)`, which seems like a valid transformation.

However, during instruction selection, the load is transformed like this:

F28464361: image.png <https://reviews.llvm.org/F28464361>

`LDRXpre(t53, 8)` is selected which is then lowered to `ldr x24, [x2, #8]!`.
Essentially transforming the offset -8 into a +8. Which is simply wrong.
The reason is, as stated above, that dec indexing modes are not respected during instruction selection on AArch64.

Usually, patterns like this don't occur. The expression `t54 = t53 - 8` is usually transformed to `t54 = t53 + (-8)` in prior optimization/transformation steps.
This can then be represented using increment indexing.

For unknown reasons, this is not the case with my sample.

Here is a drastically reduced version of the sample (which is still pretty big 🙁), that shows the issue: https://godbolt.org/z/sn5n9r96v One can see `ldr     x24, [x2, #8]!` in line 65, which should instead be a -8.
It is to note, that the sample is highly sensitive to changes. The slightest adaptation will not trigger the bug anymore.

It is to note that switching to llc (trunk) yields indeed the correct result. The reason for that is that the subtraction is previously transformed into an addtion, which is not represented as a decrement load. Again, that is because the slightest change won't trigger the bug anymore.

However, this makes it extremely difficult to design a test case.
I tried reducing my initial sample as much as possible, however, the semantics in that godbolt sample are meaningless and it is still way too big, which does not make for a good test in my opinion.
Ontop of that, in my specific case, the issue does not occur anymore with the latest version of llc.

However, I still feel like the initial issue should be fixed, hence this commit.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D156396