[llvm-dev] Register Dataflow Analysis on X86
scott constable via llvm-dev
llvm-dev at lists.llvm.org
Mon Feb 24 15:55:09 PST 2020
Hi Krzysztof,
I have been using RDF on x86 with a lot of success, though I have
encountered one weird corner case on several occasions in
getLandingPadLiveIns(). I have annotated the code below to highlight the
issue:
RegisterSet DataFlowGraph::getLandingPadLiveIns() const {
RegisterSet LR;
const Function &F = MF.getFunction();
const Constant *PF = F.hasPersonalityFn() ? F.getPersonalityFn() // PF
may be nullptr
: nullptr;
const TargetLowering &TLI = *MF.getSubtarget().getTargetLowering();
if (RegisterId R = TLI.getExceptionPointerRegister(PF))
LR.insert(RegisterRef(R));
if (RegisterId R = TLI.getExceptionSelectorRegister(PF)) // when PF is
nullptr, an assertion fails in the X86 subtarget impl
LR.insert(RegisterRef(R));
return LR;
}
The assertion fail then looks like this:
llvm/lib/Target/X86/X86ISelLowering.cpp:22945: virtual unsigned int
llvm::X86TargetLowering::getExceptionSelectorRegister(const llvm::Constant
*) const: Assertion
`!isFuncletEHPersonality(classifyEHPersonality(PersonalityFn))' failed.
Could you clarify what the issue may be, and how it might be fixed? (BTW I
am using LLVM 8.0.1)
Thanks,
Scott Constable
On Fri, Jan 10, 2020 at 6:02 AM Krzysztof Parzyszek <kparzysz at quicinc.com>
wrote:
> Hi Scott,
>
> Sorry for the late reply, I was out of office during the holidays.
>
>
>
> 1. A def node can reach either a use node, or another def node. In
> the highlighted phi node (p3224), the def (d3225) reaches another def
> (1598) in statement (s1597), that’s why it’s needed.
> 2. The reason why the def of R11 in s1578 is not connected directly to
> the use in s1725 is that there may be an intervening def between them (that
> phi node of the register mask may be one such def).
>
>
>
> --
>
> Krzysztof Parzyszek kparzysz at quicinc.com AI tools development
>
>
>
> *From:* Scott Douglas Constable <sdconsta at syr.edu>
> *Sent:* Friday, December 27, 2019 5:58 PM
> *To:* Krzysztof Parzyszek <kparzysz at quicinc.com>
> *Cc:* llvm-dev at lists.llvm.org
> *Subject:* [EXT] Re: [llvm-dev] Register Dataflow Analysis on X86
>
>
>
> Hi Krzysztof,
>
>
>
> Thanks for the reply, I'm starting to understand the graph structure and
> terminology much better now, especially with the document in RDFGraph.h.
> I'm still a bit confused about some of the behavior I'm seeing with the phi
> nodes that involve aggregate registers. Here is one example:
>
>
>
> b1531: --- %bb.36 --- preds(2): %bb.35, %bb.128 succs(1): %bb.37
> p3193: phi [+d3194<RBP>(,,u3211):, u3195<RBP>(+d3170,b1526):u1437,
> u3196<RBP>(d2141,b2486):u2324]
> p3197: phi [+d3198<RBX>(,,u3216):, u3199<RBX>(+d3138,b1526):u1465,
> u3200<RBX>(+d3364,b2486):]
> p3201: phi [+d3202<R12D>(,d1541,):, u3203<R12D>(+d3146,b1526):,
> u3204<R12D>(d1878,b2486):u3148]
> p3205: phi [+d3206<#1073741833>(,d1551,u1552):,
> u3207"<#1073741833>(d1521,b1526):u1524, u3779"<#1073741833>(d1517,b1526):,
> u3780"<#1073741833>(d1513,b1526):u1522,
> u3208"<#1073741833>(d2481,b2486):u2484, u3695"<#1073741833>(d2477,b2486):,
> u3696"<#1073741833>(d2473,b2486):u2482]
> s1532: ADJCALLSTACKDOWN64 [d1533<RSP>!(+d3206,\~d3647",u1557):,
> d1534<EFLAGS>!(+d3206,d1540,):d1533,
> d1535<SSP>!(+d3206,\~d3646",u1558):d1534, u1536<RSP>!(+d3206):,
> u1537<SSP>!(+d3206):u1536]
> s1538: MOV32r0 [d1539<R12D>(+d3202,,):,
> d1540<EFLAGS>!(d1534,d1549,):, d1541<R12>(+d3202,,u3221):d1539]
> s1542: MOV32ri64 [d1543<RDX>(+d3206,\~d3645",u1561):d1535]
> s1544: COPY [d1545<RDI>(+d3206,\~d3644",u1559):d1543,
> u1546<R13>(d785):]
> s1547: MOV32r0 [d1548<ESI>(+d3206,\~d3643",u1560):d1545,
> d1549<EFLAGS>!(d1540,\~d3642",):]
> s1550: MOV64rm [d1551<R11>(+d3206,\~d1554",u1562):d1548,
> u1552<RIP>(+d3206):u1537]
> s1553: CALL64pcrel32 __foo [\~d1554"<#1073741833>!(d1551,d1579,):,
> \~d3642"<#1073741833>!(d1549,,):, \~d3643"<#1073741833>!(d1548,,):,
> \~d3644"<#1073741833>!(d1545,,):, \~d3645"<#1073741833>!(d1543,,):,
> \~d3646"<#1073741833>!(d1535,,):, \~d3647"<#1073741833>!(d1533,,):,
> d1555<RSP>!(\~d1554",d1564,u1567):,
> d1556<SSP>!(\~d1554",d1566,u1568):d1555, u1557<RSP>!(d1533):,
> u1558<SSP>!(d1535):, u1559<RDI>!(d1545):, u1560<ESI>!(d1548):,
> u1561<RDX>!(d1543):, u1562<R11>!(d1551):]
> s1563: ADJCALLSTACKUP64 [d1564<RSP>!(d1555,,u3778"):,
> d1565<EFLAGS>!(\~d1554",d1571,):d1556, d1566<SSP>!(d1556,,u3777"):,
>
> u1567<RSP>!(d1555):, u1568<SSP>!(d1556):]
> s1569: MOV32r0 [d1570<R10D>(\~d1554",,u3776"):d1565,
> d1571<EFLAGS>!(d1565,d1574,):]
> s1572: MOV32r0 [d1573<R8D>(\~d1554",,u3775"):d1570,
> d1574<EFLAGS>!(d1571,d1577,):]
> s1575: MOV32r0 [d1576<R9D>(\~d1554",,u3774"):d1573,
> d1577<EFLAGS>!(d1574,,u3773"):]
> ---> s1578: MOV64rm [d1579<R11>(\~d1554",,u3226"):d1576]
>
>
>
> b1580: --- %bb.37 --- preds(3): %bb.36, %bb.49, %bb.64 succs(1):
> %bb.38
> p3209: phi [+d3210<RBP>(,d1731,u3212):, u3211<RBP>(+d3194,b1531):,
> u3212<RBP>(+d3210,b1710):, u3213<RBP>(d1857,b1874):u3466]
> p3214: phi [+d3215<RBX>(,,u3217):, u3216<RBX>(+d3198,b1531):,
> u3217<RBX>(+d3215,b1710):u3257, u3218<RBX>(+d3290,b1874):u3470]
> p3219: phi [+d3220<R12D>(,d1712,u1714):, u3221<R12D>(d1541,b1531):,
> u3222<R12D>(d1712,b1710):u1717, u3223<R12D>(d1878,b1874):u3204]
> ---> p3224: phi [+d3225<#1073741833>(,d1598,):,
> u3226"<#1073741833>(d1579,b1531):, u3773"<#1073741833>(d1577,b1531):,
> u3774"<#1073741833>(d1576,b1531):, u3775"<#1073741833>(d1573,b1531):,
> u3776"<#1073741833>(d1570,b1531):, u3777"<#1073741833>(d1566,b1531):,
> u3778"<#1073741833>(d1564,b1531):, u3227<#1073741833>(d1716,b1710):u1719,
> u3228"<#1073741833>(d1885,b1874):u3751",
> u3754"<#1073741833>(d1880,b1874):u1887,
> u3755"<#1073741833>(d1865,b1874):u3752",
> u3756"<#1073741833>(d1861,b1874):u3753"]
> s1581: IMUL64rri8 [d1582<RAX>(+d3225,d1596,u1592):,
> d1583<EFLAGS>!(+d3225,d1595,):d1582, u1584<R12>(+d3220):]
> s1585: LEA64r [d1586<RSI>(+d3225,,u3772"):d1583, u1587<R15>(d776):,
> u1588<RAX>(d1582):]
> s1589: LEA64r [d1590<RDI>(+d3225,,u3771"):d1586,
> u1591<R14>(+d3142):u1455, u1592<RAX>(d1582):u1588]
> s1593: MOV32r0 [d1594<EAX>(d1582,,):, d1595<EFLAGS>!(d1583,d1599,):,
> d1596<RAX>(d1582,,u3770"):d1594]
> s1597: MOV32r0 [d1598<ECX>(+d3225,,u3769"):d1590,
> d1599<EFLAGS>!(d1595,,u3231"):]
>
> I have used arrows to highlight two nodes. The first node, s1578, def's
> d1579<R11>, which has a single reached use in phi node p3224. I am
> surprised that this phi node exists and has no reached uses, for two
> reasons. First, I built the graph without the KeepDeadPhis option.
> Shouldn't this remove phi nodes without reached uses? Second, there clearly
> *is* a reached use of R11 (corresponding to the instruction represented
> by s1578) in another basic block:
>
>
>
> b1721: --- %bb.50 --- preds(1): %bb.49 succs(1): %bb.51
> s1722: COPY [d1723<RSI>(+d3248,,u3765"):d1713, u1724<R13>(d785):u1546]
> ---> s1725: COPY [d1726<RDI>(+d3248,,u3764"):d1723, u1727<R11>(+d3248):]
> s1728: MOV32r0 [d1729<EBP>(+d3210,,):,
> d1730<EFLAGS>!(d1716,,u3261"):, d1731<RBP>(+d3210,,u3253):d1729]
>
>
>
> I have confirmed via manual inspection and the use of a dynamic analysis
> tool that the next use of the R11 def in s1578 is s1725.
>
>
>
> Could you please clarify these two points?
>
>
>
> Thanks,
>
>
>
> Scott
>
>
>
> On Mon, Dec 23, 2019 at 12:46 PM Krzysztof Parzyszek <kparzysz at quicinc.com>
> wrote:
>
> Hi Scott,
>
> That #1073741833 is a register mask. They are treated as aggregate
> registers (essentially sets of registers), so if it includes R9D and R11D,
> it will be treated as being aliased with both.
>
>
>
> These separate defs are there because they reach disjoint registers.
>
>
>
>
>
> --
>
> Krzysztof Parzyszek kparzysz at quicinc.com AI tools development
>
>
>
> *From:* Scott Douglas Constable <sdconsta at syr.edu>
> *Sent:* Monday, December 23, 2019 2:10 PM
> *To:* Scott Douglas Constable <sdconsta at syr.edu>
> *Cc:* Krzysztof Parzyszek <kparzysz at quicinc.com>; llvm-dev at lists.llvm.org
> *Subject:* [EXT] Re: [llvm-dev] Register Dataflow Analysis on X86
>
>
>
> Revisiting this thread. I have been experimenting with the RDF module on
> the X86 target. For the most part, building the data-flow graph and
> following def-use chains seems to work fine. But I am also observing some
> strange behavior in the phi nodes. For example, I have one basic block
> which begins with the following 4 phi nodes:
>
>
>
> b585: --- %bb.25 --- preds(5): %bb.24, %bb.20, %bb.22, %bb.49, %bb.52
> succs(2): %bb.18, %bb.37
> p1095: phi [+d1096<EBP>(,d668,):, u1097<EBP>(d540,b477):u555,
> u1098<EBP>(d427,b448):u450, u1099<EBP>(d427,b462):u464,
> u1100<EBP>(d427,b1009):u1011, u1101<EBP>(d427,b1027):u1029]
> p1102: phi [+d1103<R13D>(,,u1075):, u1104<R13D>(d557,b477):u563,
> u1105<R13D>(d411,b448):, u1106<R13D>(d411,b462):u459,
> u1107<R13D>(d411,b1009):u1106, u1108<R13D>(d411,b1027):u1107]
> p1109: phi [+d1110<R14D>(,d625,u612):, u1111<R14D>(d584,b477):,
> u1112<R14D>(d452,b448):, u1113<R14D>(d466,b462):,
> u1114<R14D>(d1013,b1009):, u1115<R14D>(d1031,b1027):]
> p1116: phi [+d1117<#1073741833>(,d645,u648):,
> u1118"<#1073741833>(d579,b477):, u1466"<#1073741833>(d578,b477):,
> u1467"<#1073741833>(d569,b477):u581, u1468"<#1073741833>(d546,b477):,
> u1469"<#1073741833>(d543,b477):, u1470"<#1073741833>(d524,b477):u530,
> u1119"<#1073741833>(d453,b448):, u1436"<#1073741833>(d420,b448):,
> u1437"<#1073741833>(d404,b448):u445, u1120"<#1073741833>(d467,b462):,
> u1438"<#1073741833>(d420,b462):u1436", u1439"<#1073741833>(d404,b462):u473,
> u1121"<#1073741833>(d1014,b1009):, u1440"<#1073741833>(d420,b1009):u1006,
> u1441"<#1073741833>(d404,b1009):u1439", u1122"<#1073741833>(d1032,b1027):,
> u1442"<#1073741833>(d420,b1027):u1440",
> u1443"<#1073741833>(d404,b1027):u1441"]
>
>
>
> The first three make perfect sense to me, and seem to reflect the
> post-allocation MIR correctly. The fourth phi node seems entirely composed
> of defs and uses for some unnamed register #1073741833 (what exactly is the
> significance of unnamed registers?). Moreover, this phi seems to be
> introducing false def-use relationships into the DFG. For example, the phi
> introduces the following dependency chain, which as far as I can tell is
> not valid:
>
>
>
> // R11D is def'ed, def ID is d524
>
> s523: SUB32rr [d524<R11D>(d519,,u1470"):, d525<EFLAGS>!(d520,d533,):,
> u526<R11D>(d519):, u527<ESI>(d508):]
> ...
>
> // d524 is used in the phi node to def d1117, corresponding to unnamed
> register #1073741833
> p1116: phi [+d1117<#1073741833>(,d645,u648):,
> u1118"<#1073741833>(d579,b477):, u1466"<#1073741833>(d578,b477):,
> u1467"<#1073741833>(d569,b477):u581, u1468"<#1073741833>(d546,b477):,
> u1469"<#1073741833>(d543,b477):, u1470"<#1073741833>(d524,b477):u530,
> u1119"<#1073741833>(d453,b448):, u1436"<#1073741833>(d420,b448):,
> u1437"<#1073741833>(d404,b448):u445, u1120"<#1073741833>(d467,b462):,
> u1438"<#1073741833>(d420,b462):u1436", u1439"<#1073741833>(d404,b462):u473,
> u1121"<#1073741833>(d1014,b1009):, u1440"<#1073741833>(d420,b1009):u1006,
> u1441"<#1073741833>(d404,b1009):u1439", u1122"<#1073741833>(d1032,b1027):,
> u1442"<#1073741833>(d420,b1027):u1440",
> u1443"<#1073741833>(d404,b1027):u1441"]
> ...
>
> // d1117 is used in def d645 of register R9D
> s644: ADD32rr [d645<R9D>(+d1117,d694,u659):d634,
> d646<EFLAGS>!(d633,d651,):, u647<R9D>(+d1117):u637, u648<R9D>(+d1117):u647]
>
>
>
> But after examining the corresponding MIR, I do not think that R11D flows
> into R9D. So it looks to me as though this phi node is erroneous.
>
>
>
> Any help wold be much appreciated!
>
>
>
> I'm using the LLVM 8.0.1 release.
>
>
>
> On Fri, Nov 8, 2019 at 10:35 AM Scott Douglas Constable via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
>
> Do you know whether it has been fixed on the 8.0.1 release?
>
>
>
> Scott
>
>
>
> On Fri, Nov 8, 2019 at 9:45 AM Krzysztof Parzyszek <kparzysz at quicinc.com>
> wrote:
>
> The one blocking issue that existed in the past has been fixed. I haven’t
> had time to do any work on it lately, but I’m not aware of any fundamental
> problems that would make it not work on x86.
>
>
>
> --
>
> Krzysztof Parzyszek kparzysz at quicinc.com AI tools development
>
>
>
> *From:* llvm-dev <llvm-dev-bounces at lists.llvm.org> *On Behalf Of *Scott
> Douglas Constable via llvm-dev
> *Sent:* Friday, November 8, 2019 10:59 AM
> *To:* llvm-dev at lists.llvm.org
> *Subject:* [EXT] [llvm-dev] Register Dataflow Analysis on X86
>
>
>
> I came across this thread from a couple years ago:
>
>
>
> http://lists.llvm.org/pipermail/llvm-dev/2017-November/119346.html
>
>
>
> Has there been any progress on RDF for X86? Or is there some other
> preferred alternative for performing reachability analysis after register
> allocation?
>
>
>
> Thanks,
>
>
>
> Scott Constable
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200224/00ed073d/attachment.html>
More information about the llvm-dev
mailing list