Scott Douglas Constable via llvm-dev
2019-Nov-08 18:35 UTC
[llvm-dev] Register Dataflow Analysis on X86
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<mailto: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<mailto:kparzysz at quicinc.com> AI tools development From: llvm-dev <llvm-dev-bounces at lists.llvm.org<mailto: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<mailto: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 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20191108/c6a2e657/attachment-0001.html>
Scott Douglas Constable via llvm-dev
2019-Dec-23 20:10 UTC
[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<mailto: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<mailto: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<mailto:kparzysz at quicinc.com> AI tools development From: llvm-dev <llvm-dev-bounces at lists.llvm.org<mailto: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<mailto: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<mailto: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/20191223/71f1f082/attachment.html>
Krzysztof Parzyszek via llvm-dev
2019-Dec-23 20:45 UTC
[llvm-dev] Register Dataflow Analysis on X86
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<mailto: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<mailto: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<mailto: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<mailto:kparzysz at quicinc.com> AI tools development From: llvm-dev <llvm-dev-bounces at lists.llvm.org<mailto: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<mailto: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<mailto: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/20191223/34727abf/attachment.html>