This is an archive of the discontinued LLVM Phabricator instance.

[PPC] Use VSX/FP Facility integer load when an integer load's only users are conversion to FP
ClosedPublic

Authored by amehsan on Mar 23 2016, 10:12 AM.

Details

Summary

The code checks when an integer load is followed by one or more direct move. If there is no other user for the integer load we can replace two instructions with one floating point load. Essentially what we do here is disabling aggressive exploitation of direct move instruction. Otherwise the code for replacing the sequence already exists and works properly.

Diff Detail

Event Timeline

amehsan updated this revision to Diff 51441.Mar 23 2016, 10:12 AM
amehsan retitled this revision from to [PPC] Prefer floating point load to integer load plus direct move, when there is no other user for the integer load.
amehsan updated this object.
amehsan added a subscriber: llvm-commits.
amehsan updated this object.Mar 23 2016, 10:14 AM
nemanjai added inline comments.Mar 23 2016, 1:28 PM
lib/Target/PowerPC/PPCISelLowering.cpp
6302

I think this only makes sense if the direct-move path wouldn't be able to use a D-Form load. In that case, you're simply eliminating one direct move instruction. However, in cases where the direct-move path would be able to use a D-Form load, we've just added another load (for the X-Form lxsiwax). For [a contrived] example:

float test (int *arr) {
  return arr[2];
}

That being said, I don't know that this would be a show-stopper for this approach as the benefits may outweigh this issue.
Also, I think you can probably predict whether the ISD::LOAD will be lowered to a D-Form load based on the inputs.
I think the complete condition when we don't want the direct move would be:

  • The input is a load
  • The only use is an int-to-fp conversion
  • The offset from the base register is either zero, non-constant or does not fit in the 16-bit D field of a D-Form load

I believe that all of these can be checked without making the code overly complicated.

6309

Just a minor nit - I think we generally prefer complete sentences for comments (capitalization, punctuation).

test/CodeGen/PowerPC/direct-move-profit.ll
5

You should probably remove the metadata here and (some) below. The triple on the command line and here conflict and I don't believe that all the metadata below is necessary.

amehsan added inline comments.Mar 28 2016, 10:17 AM
lib/Target/PowerPC/PPCISelLowering.cpp
6302

We discussed this over email. This is a summary of our conclusion.

The current patch for deciding whether or not we should use direct move is fine. The code generated for the example above (after this patch) is:

0:   08 00 80 38     li      r4,8
4:   98 20 03 7c     lxsiwax vs0,r3,r4
8:   e0 04 20 f0     xscvsxdsp vs1,vs0
c:   20 00 80 4e     blr

Ideally it should be like what gcc does:

0:   08 00 63 38     addi    r3,r3,8
4:   ae 1e 20 7c     lfiwax  f1,0,r3
8:   9c 0e 20 ec     fcfids  f1,f1
c:   20 00 80 4e     blr

The second code pattern has lower register pressure and that is why it is better. The code that generates first code pattern above was previously used only for Power7. After this patch this code is now used for Power8. The example exposes an opportunity within the new code path. That will be addressed separately from this patch.

kbarton requested changes to this revision.Apr 4 2016, 1:10 PM
kbarton edited edge metadata.
kbarton added inline comments.
lib/Target/PowerPC/PPCISelLowering.cpp
6302

OK, I'm confused by these comments.

With this patch, what code sequence is going to be generated?
If there is a further opportunity, why not address it with this patch? If it really makes sense to deal with it in a separate patch, please list the phabricator review (or bugzilla) for it here, so we can be sure to track it and maintain the association between the items.

6389–6390

I have a very slight preference for checking whether DirectMove is available before checking whether it is profitable.
Changing the order of the checks will have virtually no impact, but it makes more sense to me.

test/CodeGen/PowerPC/direct-move-profit.ll
5

I agree. Please remove this, and the target triple line immediately below, and specify the correct triple on the RUN step.

This revision now requires changes to proceed.Apr 4 2016, 1:10 PM
amehsan added inline comments.Apr 4 2016, 1:19 PM
lib/Target/PowerPC/PPCISelLowering.cpp
6302

The first sequence is the one generated after this patch. The second sequence is the one currently gcc generates. The one that is generated before this patch is this:

0:   08 00 63 80     lwz     r3,8(r3)
4:   a6 01 03 7c     mtfprwa f0,r3
8:   e0 04 20 f0     xscvsxdsp vs1,vs0
c:   20 00 80 4e     blr
amehsan added inline comments.Apr 4 2016, 2:31 PM
lib/Target/PowerPC/PPCISelLowering.cpp
6302

I discussed this with Kit offline. I will address the requested change in the test case (making sure meta data is correct) and two nits suggested below. After final approval I will commit this change. The bug exposed by this patch (which was discussed in the comments above) will be addressed separately under the following bugzilla item.

https://llvm.org/bugs/show_bug.cgi?id=27204

amehsan updated this revision to Diff 52721.Apr 5 2016, 12:06 PM
amehsan edited edge metadata.

Removed data layout and redundant triple definition from the test case.
Capitalized comment in the code.
Minor change in the if statement which has the new condition. (Changed the order of two conditions)

amehsan marked 3 inline comments as done.Apr 5 2016, 12:07 PM
mcrosier added inline comments.
lib/Target/PowerPC/PPCISelLowering.cpp
6309

Please add a space between the "//" and the comments.

6389–6390

The calls to the Subtarget.* are likely very cheap, while the call to directMoveIsProfitable is less so. I'd suggest checking the directMoveIsProfitable() last.

test/CodeGen/PowerPC/direct-move-profit.ll
7

Please add a space after the semicolon.

amehsan added inline comments.Apr 5 2016, 12:28 PM
lib/Target/PowerPC/PPCISelLowering.cpp
6389–6390

Actually, calls to the Subtarget.* are going to be always successful unless someone is compiling for Power 7 or below (which is not very likely) or is doing some work with the testcases. So for almost all practical purposes, we will always call directMoeIsProfitable and make the decision based on that.

amehsan updated this revision to Diff 52725.Apr 5 2016, 12:36 PM
amehsan edited edge metadata.

adding space after comments

amehsan marked 2 inline comments as done.Apr 5 2016, 12:36 PM
mcrosier added inline comments.Apr 5 2016, 12:38 PM
lib/Target/PowerPC/PPCISelLowering.cpp
6389–6390

Fair enough. :)

amehsan added inline comments.Apr 5 2016, 12:47 PM
lib/Target/PowerPC/PPCISelLowering.cpp
6389–6390

:)

kbarton accepted this revision.Apr 6 2016, 8:48 AM
kbarton edited edge metadata.

LGTM

This revision is now accepted and ready to land.Apr 6 2016, 8:48 AM
amehsan retitled this revision from [PPC] Prefer floating point load to integer load plus direct move, when there is no other user for the integer load to [PPC] Use VSX/FP Facility integer load when an integer load's only users are conversion to FP.Apr 6 2016, 1:13 PM
amehsan edited edge metadata.

committed r265593.

amehsan closed this revision.Apr 6 2016, 8:05 PM