This is an archive of the discontinued LLVM Phabricator instance.

[PowerPC] Don't reuse the address of an illegal typed load for int_to_fp.
ClosedPublic

Authored by sfertile on Nov 11 2020, 7:46 AM.

Details

Summary

When the operand to an (s/u)int_to_fp node is an illegally typed load we cannot reuse the load address since we can't build a proper dependancy chain. The legalized loads will use a different chain output then the illegal load. If we reuse the load address then we will build a conversion node that uses the chain of the illegal load and operations which modify the memory address in the other dependancy chain can be scheduled before the floating point load which feeds the conversion.

Diff Detail

Event Timeline

sfertile created this revision.Nov 11 2020, 7:46 AM
Herald added a project: Restricted Project. · View Herald TranscriptNov 11 2020, 7:46 AM
sfertile requested review of this revision.Nov 11 2020, 7:46 AM
ZarkoCA accepted this revision.Nov 18 2020, 6:38 AM
ZarkoCA added inline comments.
llvm/test/CodeGen/PowerPC/cvt_i64_to_fp.ll
4

Out of curiousity, is there a reason for specifying freebsd vs linux?

7

nit: I don't think you need the #0 here.

This revision is now accepted and ready to land.Nov 18 2020, 6:38 AM
nemanjai accepted this revision.Nov 20 2020, 3:45 AM

The patch LGTM, but I really think the test case should change to more clearly convey the behaviour you desire to test.

llvm/test/CodeGen/PowerPC/cvt_i64_to_fp.ll
16

Am I misreading this? It looks like the test is actually testing for the undesired behaviour. Namely, we load the value from the parameter pointer (presumably increment it there), store it to stack - 8, then load it from stack - 8 into an FPR and convert.

Of course, this comment is tongue-in-cheek and I assume that the stores to the stack are before the increment and there are a pair of stores to the parameter pointer of the incremented value - but there is nothing in this test case to show that. Namely, this would equivalently match this wrong sequence:

lwz 5, 4(3)
addic 5, 5, 1
stw 5, -4(1)
stw 5, 4(3)
lwz 5, 0(3)
addze 5, 5
stw 5, -8(1)
stw 5, 0(3)
lfd 1, -8(1)
fcfid 1, 1

So my advice is to use the script to produce the checks as it is more maintainable and easy to prevent issues such as this. However, if you prefer not to use it, you should at least show the increment and the other stores to show that we are storing the incremented value to the parameter pointer and the non-incremented value to the stack.

This revision was landed with ongoing or failed builds.Nov 24 2020, 12:48 PM
This revision was automatically updated to reflect the committed changes.