[llvm-dev] Register Dataflow Analysis on X86

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

[llvm-dev] Register Dataflow Analysis on X86

Jeremy Morse via llvm-dev
I came across this thread from a couple years ago:


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
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
Reply | Threaded
Open this post in threaded view
|

Re: [llvm-dev] Register Dataflow Analysis on X86

Jeremy Morse via llvm-dev

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  [hidden email]   AI tools development

 

From: llvm-dev <[hidden email]> On Behalf Of Scott Douglas Constable via llvm-dev
Sent: Friday, November 8, 2019 10:59 AM
To: [hidden email]
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
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
Reply | Threaded
Open this post in threaded view
|

Re: [llvm-dev] Register Dataflow Analysis on X86

Jeremy Morse via llvm-dev
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 <[hidden email]> 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  [hidden email]   AI tools development

 

From: llvm-dev <[hidden email]> On Behalf Of Scott Douglas Constable via llvm-dev
Sent: Friday, November 8, 2019 10:59 AM
To: [hidden email]
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
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
Reply | Threaded
Open this post in threaded view
|

Re: [llvm-dev] Register Dataflow Analysis on X86

Jeremy Morse via llvm-dev
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 <[hidden email]> 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 <[hidden email]> 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  [hidden email]   AI tools development

 

From: llvm-dev <[hidden email]> On Behalf Of Scott Douglas Constable via llvm-dev
Sent: Friday, November 8, 2019 10:59 AM
To: [hidden email]
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
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

_______________________________________________
LLVM Developers mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
Reply | Threaded
Open this post in threaded view
|

Re: [llvm-dev] Register Dataflow Analysis on X86

Jeremy Morse via llvm-dev

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  [hidden email]   AI tools development

 

From: Scott Douglas Constable <[hidden email]>
Sent: Monday, December 23, 2019 2:10 PM
To: Scott Douglas Constable <[hidden email]>
Cc: Krzysztof Parzyszek <[hidden email]>; [hidden email]
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 <[hidden email]> 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 <[hidden email]> 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  [hidden email]   AI tools development

 

From: llvm-dev <[hidden email]> On Behalf Of Scott Douglas Constable via llvm-dev
Sent: Friday, November 8, 2019 10:59 AM
To: [hidden email]
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
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev


_______________________________________________
LLVM Developers mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
Reply | Threaded
Open this post in threaded view
|

Re: [llvm-dev] Register Dataflow Analysis on X86

Jeremy Morse via llvm-dev
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 <[hidden email]> 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  [hidden email]   AI tools development

 

From: Scott Douglas Constable <[hidden email]>
Sent: Monday, December 23, 2019 2:10 PM
To: Scott Douglas Constable <[hidden email]>
Cc: Krzysztof Parzyszek <[hidden email]>; [hidden email]
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 <[hidden email]> 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 <[hidden email]> 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  [hidden email]   AI tools development

 

From: llvm-dev <[hidden email]> On Behalf Of Scott Douglas Constable via llvm-dev
Sent: Friday, November 8, 2019 10:59 AM
To: [hidden email]
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
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev


_______________________________________________
LLVM Developers mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
Reply | Threaded
Open this post in threaded view
|

Re: [llvm-dev] Register Dataflow Analysis on X86

Jeremy Morse via llvm-dev

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  [hidden email]   AI tools development

 

From: Scott Douglas Constable <[hidden email]>
Sent: Friday, December 27, 2019 5:58 PM
To: Krzysztof Parzyszek <[hidden email]>
Cc: [hidden email]
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 <[hidden email]> 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  [hidden email]   AI tools development

 

From: Scott Douglas Constable <[hidden email]>
Sent: Monday, December 23, 2019 2:10 PM
To: Scott Douglas Constable <[hidden email]>
Cc: Krzysztof Parzyszek <[hidden email]>; [hidden email]
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 <[hidden email]> 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 <[hidden email]> 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  [hidden email]   AI tools development

 

From: llvm-dev <[hidden email]> On Behalf Of Scott Douglas Constable via llvm-dev
Sent: Friday, November 8, 2019 10:59 AM
To: [hidden email]
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
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev


_______________________________________________
LLVM Developers mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
Reply | Threaded
Open this post in threaded view
|

Re: [llvm-dev] Register Dataflow Analysis on X86

Jeremy Morse via llvm-dev
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 <[hidden email]> 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  [hidden email]   AI tools development

 

From: Scott Douglas Constable <[hidden email]>
Sent: Friday, December 27, 2019 5:58 PM
To: Krzysztof Parzyszek <[hidden email]>
Cc: [hidden email]
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 <[hidden email]> 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  [hidden email]   AI tools development

 

From: Scott Douglas Constable <[hidden email]>
Sent: Monday, December 23, 2019 2:10 PM
To: Scott Douglas Constable <[hidden email]>
Cc: Krzysztof Parzyszek <[hidden email]>; [hidden email]
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 <[hidden email]> 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 <[hidden email]> 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  [hidden email]   AI tools development

 

From: llvm-dev <[hidden email]> On Behalf Of Scott Douglas Constable via llvm-dev
Sent: Friday, November 8, 2019 10:59 AM
To: [hidden email]
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
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev


_______________________________________________
LLVM Developers mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
Reply | Threaded
Open this post in threaded view
|

Re: [llvm-dev] Register Dataflow Analysis on X86

Jeremy Morse via llvm-dev

Hi Scott,

 

This code is trying to collect the registers that are live-in on entry to the landing pad.  As you probably know, the landing pads are where the exception handling runtime jumps back into the function, so they are something like additional entry points.  As such, they have some set of live-in registers as defined by some calling convention (or more likely exception handling convention).  All this code does is trying to find out what these registers are.  What this assertion reflects is really my lack of familiarity with these conventions for x86.  This function is kind of “one size fits all”, i.e. “do the same thing for all cases”, which is evidently not sufficient.  The proper fix would be to identify the applicable calling convention for a particular case and set the live-in registers appropriately.

Here’s a document about exception handling in LLVM with some information about landing pads and funclets: the actual registers depend on the target OS (Linux/Windows), and also on the architecture (I’m guessing this is 32- vs 64-bit).

https://llvm.org/docs/ExceptionHandling.html

 

I’m happy to hear that you’re funding RDF useful.

 

--

Krzysztof Parzyszek  [hidden email]   AI tools development

 

From: scott constable <[hidden email]>
Sent: Monday, February 24, 2020 5:55 PM
To: Krzysztof Parzyszek <[hidden email]>; [hidden email]
Subject: [EXT] Re: [llvm-dev] Register Dataflow Analysis on X86

 

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 <[hidden email]> 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  [hidden email]   AI tools development

 

From: Scott Douglas Constable <[hidden email]>
Sent: Friday, December 27, 2019 5:58 PM
To: Krzysztof Parzyszek <[hidden email]>
Cc: [hidden email]
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 <[hidden email]> 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  [hidden email]   AI tools development

 

From: Scott Douglas Constable <[hidden email]>
Sent: Monday, December 23, 2019 2:10 PM
To: Scott Douglas Constable <[hidden email]>
Cc: Krzysztof Parzyszek <[hidden email]>; [hidden email]
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 <[hidden email]> 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 <[hidden email]> 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  [hidden email]   AI tools development

 

From: llvm-dev <[hidden email]> On Behalf Of Scott Douglas Constable via llvm-dev
Sent: Friday, November 8, 2019 10:59 AM
To: [hidden email]
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
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev


_______________________________________________
LLVM Developers mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev