Hi all, Following the thread from http://lists.llvm.org/pipermail/llvm-dev/2017-January/109029.html, I am sending this email to give a status on GlobalISel progress and situation. We are pushing GlobalISel from the state of prototype to a production quality framework. We welcome help with patches, reviews, feedbacks and so on. As explained during the last developer meeting, we are aiming at enabling GISel by default for AArch64 at -O0 for this year (See http://llvm.org/devmtg/2016-11/#talk16). Note: That does not mean the design is settle nor that we won’t change the APIs. Note: A lot of the things listed in this email is a reminder of what we said during the dev meeting talk. *** High Level View *** As of r292481, we compile and run correctly with GISel (without fall back to SDISel) 63% of the LLVM test suite. If you are interested in detailed numbers, please see the attachments (courtesy of Kristof Beyls). Note: The compile time numbers are probably noisy (compiled in parallel on the same machine), and not relevant at this point of the project anyway. *** Per Pass Status *** ** IRTranslator ** Mostly done. * What’s Left? * Some instructions are not yet supported. ** Legalizer ** Core logic is present. * What’s Left? * - A lot of instructions are missing, in particular the vector ones. - Legalization of G_SEQUENCE/G_EXTRACT still up in the air for complex cases. Note: The lack of broad vector support is one on the reason we target O0, i.e., the vectorizer doesn’t run and we are less likely to hit the missing implementation. ** RegBankSelect ** - Core logic is present, no optimizations yet, or more accurately, the greedy mode is still pretty silly. - TableGen support for RegisterBanks description. * What’s Left * - TableGen the instruction mapping from the existing SDISel patterns. - Improve the optimization heuristic. ** InstructionSelect ** - Core logic present. - TableGen support for simple SDISel patterns (i.e., GISel reuses SDISel patterns) * What’s Left * - Teach TableGen how to reuse more complex patterns: — Patterns with combines in them (e.g., (mull (add)) => madd) — Patterns with complex patterns (e.g., SelectAddressModXR0) *** On Going Work *** - General approach: use AArch64 O0 on the LLVM test suite as a driving vehicle to guide what to support next in the various passes. - Extend TableGen support to reuse more and more SDISel patterns. - ARM port. - AMDGPU port. - X86 port. If you have questions, don’t hesitate! Cheers, -Quentin -------------- next part -------------- A non-text attachment was scrubbed... Name: 292481_gisel_testsuite_status.xlsx Type: application/vnd.openxmlformats-officedocument.spreadsheetml.sheet Size: 51857 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170120/d2f10d76/attachment-0001.xlsx>
Quentin, do you have some links you can share for guidance for those that might want to jump in to start preparing other targets for Global ISEL? On Sat, Jan 21, 2017 at 2:19 AM, Quentin Colombet via llvm-dev < llvm-dev at lists.llvm.org> wrote:> Hi all, > > Following the thread from http://lists.llvm.org/pipermail/llvm-dev/2017- > January/109029.html, I am sending this email to give a status on > GlobalISel progress and situation. > > We are pushing GlobalISel from the state of prototype to a production > quality framework. We welcome help with patches, reviews, feedbacks and so > on. > > As explained during the last developer meeting, we are aiming at enabling > GISel by default for AArch64 at -O0 for this year (See > http://llvm.org/devmtg/2016-11/#talk16). > > Note: That does not mean the design is settle nor that we won’t change the > APIs. > Note: A lot of the things listed in this email is a reminder of what we > said during the dev meeting talk. > > *** High Level View *** > > As of r292481, we compile and run correctly with GISel (without fall back > to SDISel) 63% of the LLVM test suite. If you are interested in detailed > numbers, please see the attachments (courtesy of Kristof Beyls). > > Note: The compile time numbers are probably noisy (compiled in parallel on > the same machine), and not relevant at this point of the project anyway. > > > *** Per Pass Status *** > > ** IRTranslator ** > > Mostly done. > > * What’s Left? * > > Some instructions are not yet supported. > > > ** Legalizer ** > > Core logic is present. > > * What’s Left? * > > - A lot of instructions are missing, in particular the vector ones. > - Legalization of G_SEQUENCE/G_EXTRACT still up in the air for complex > cases. > > Note: The lack of broad vector support is one on the reason we target O0, > i.e., the vectorizer doesn’t run and we are less likely to hit the missing > implementation. > > > ** RegBankSelect ** > > - Core logic is present, no optimizations yet, or more accurately, the > greedy mode is still pretty silly. > - TableGen support for RegisterBanks description. > > * What’s Left * > > - TableGen the instruction mapping from the existing SDISel patterns. > - Improve the optimization heuristic. > > > ** InstructionSelect ** > > - Core logic present. > - TableGen support for simple SDISel patterns (i.e., GISel reuses SDISel > patterns) > > * What’s Left * > > - Teach TableGen how to reuse more complex patterns: > — Patterns with combines in them (e.g., (mull (add)) => madd) > — Patterns with complex patterns (e.g., SelectAddressModXR0) > > > *** On Going Work *** > > - General approach: use AArch64 O0 on the LLVM test suite as a driving > vehicle to guide what to support next in the various passes. > - Extend TableGen support to reuse more and more SDISel patterns. > - ARM port. > - AMDGPU port. > - X86 port. > > If you have questions, don’t hesitate! > > Cheers, > -Quentin > > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > http://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/20170121/7e685b5c/attachment.html>
Hi Quentin, My understanding is that throughout the GISel lowering process all the lowering steps use the same underlying MI representation, but have different invariants at different points in time (for example, G_ opcodes may be present at some point but it would be an "assert" failure to see them at other points). Are there currently any plans (or things already implemented) to verify that these invariants hold at different points throughout the lowering pipeline? Also, in order to run passes in isolation, ideally they would have nice, easily-understandable failure modes if you feed them MIR with invariants they don't expect. The reason I bring this up is that at work I'm currently working on a compiler (not llvm-based) which does its lowering on a single IR and this is one of the most consistent pain points. In LLVM we already have this problem in the form of e.g. pre-RA and post-RA MI, but it seems like GISel is going to magnify this significantly. -- Sean Silva On Fri, Jan 20, 2017 at 5:19 PM, Quentin Colombet via llvm-dev < llvm-dev at lists.llvm.org> wrote:> Hi all, > > Following the thread from http://lists.llvm.org/pipermail/llvm-dev/2017- > January/109029.html, I am sending this email to give a status on > GlobalISel progress and situation. > > We are pushing GlobalISel from the state of prototype to a production > quality framework. We welcome help with patches, reviews, feedbacks and so > on. > > As explained during the last developer meeting, we are aiming at enabling > GISel by default for AArch64 at -O0 for this year (See > http://llvm.org/devmtg/2016-11/#talk16). > > Note: That does not mean the design is settle nor that we won’t change the > APIs. > Note: A lot of the things listed in this email is a reminder of what we > said during the dev meeting talk. > > *** High Level View *** > > As of r292481, we compile and run correctly with GISel (without fall back > to SDISel) 63% of the LLVM test suite. If you are interested in detailed > numbers, please see the attachments (courtesy of Kristof Beyls). > > Note: The compile time numbers are probably noisy (compiled in parallel on > the same machine), and not relevant at this point of the project anyway. > > > *** Per Pass Status *** > > ** IRTranslator ** > > Mostly done. > > * What’s Left? * > > Some instructions are not yet supported. > > > ** Legalizer ** > > Core logic is present. > > * What’s Left? * > > - A lot of instructions are missing, in particular the vector ones. > - Legalization of G_SEQUENCE/G_EXTRACT still up in the air for complex > cases. > > Note: The lack of broad vector support is one on the reason we target O0, > i.e., the vectorizer doesn’t run and we are less likely to hit the missing > implementation. > > > ** RegBankSelect ** > > - Core logic is present, no optimizations yet, or more accurately, the > greedy mode is still pretty silly. > - TableGen support for RegisterBanks description. > > * What’s Left * > > - TableGen the instruction mapping from the existing SDISel patterns. > - Improve the optimization heuristic. > > > ** InstructionSelect ** > > - Core logic present. > - TableGen support for simple SDISel patterns (i.e., GISel reuses SDISel > patterns) > > * What’s Left * > > - Teach TableGen how to reuse more complex patterns: > — Patterns with combines in them (e.g., (mull (add)) => madd) > — Patterns with complex patterns (e.g., SelectAddressModXR0) > > > *** On Going Work *** > > - General approach: use AArch64 O0 on the LLVM test suite as a driving > vehicle to guide what to support next in the various passes. > - Extend TableGen support to reuse more and more SDISel patterns. > - ARM port. > - AMDGPU port. > - X86 port. > > If you have questions, don’t hesitate! > > Cheers, > -Quentin > > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > http://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/20170121/59369819/attachment.html>
Ah, I see you mentioned it briefly here: https://youtu.be/6tfb344A7w8?t=15m25s And it is also mentioned here: http://llvm.org/docs/GlobalISel.html#machineverifier -- Sean Silva On Sat, Jan 21, 2017 at 11:19 PM, Sean Silva <chisophugis at gmail.com> wrote:> Hi Quentin, > > My understanding is that throughout the GISel lowering process all the > lowering steps use the same underlying MI representation, but have > different invariants at different points in time (for example, G_ opcodes > may be present at some point but it would be an "assert" failure to see > them at other points). Are there currently any plans (or things already > implemented) to verify that these invariants hold at different points > throughout the lowering pipeline? Also, in order to run passes in > isolation, ideally they would have nice, easily-understandable failure > modes if you feed them MIR with invariants they don't expect. > > The reason I bring this up is that at work I'm currently working on a > compiler (not llvm-based) which does its lowering on a single IR and this > is one of the most consistent pain points. In LLVM we already have this > problem in the form of e.g. pre-RA and post-RA MI, but it seems like GISel > is going to magnify this significantly. > > > -- Sean Silva > > On Fri, Jan 20, 2017 at 5:19 PM, Quentin Colombet via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> Hi all, >> >> Following the thread from http://lists.llvm.org/pipermai >> l/llvm-dev/2017-January/109029.html, I am sending this email to give a >> status on GlobalISel progress and situation. >> >> We are pushing GlobalISel from the state of prototype to a production >> quality framework. We welcome help with patches, reviews, feedbacks and so >> on. >> >> As explained during the last developer meeting, we are aiming at enabling >> GISel by default for AArch64 at -O0 for this year (See >> http://llvm.org/devmtg/2016-11/#talk16). >> >> Note: That does not mean the design is settle nor that we won’t change >> the APIs. >> Note: A lot of the things listed in this email is a reminder of what we >> said during the dev meeting talk. >> >> *** High Level View *** >> >> As of r292481, we compile and run correctly with GISel (without fall back >> to SDISel) 63% of the LLVM test suite. If you are interested in detailed >> numbers, please see the attachments (courtesy of Kristof Beyls). >> >> Note: The compile time numbers are probably noisy (compiled in parallel >> on the same machine), and not relevant at this point of the project anyway. >> >> >> *** Per Pass Status *** >> >> ** IRTranslator ** >> >> Mostly done. >> >> * What’s Left? * >> >> Some instructions are not yet supported. >> >> >> ** Legalizer ** >> >> Core logic is present. >> >> * What’s Left? * >> >> - A lot of instructions are missing, in particular the vector ones. >> - Legalization of G_SEQUENCE/G_EXTRACT still up in the air for complex >> cases. >> >> Note: The lack of broad vector support is one on the reason we target O0, >> i.e., the vectorizer doesn’t run and we are less likely to hit the missing >> implementation. >> >> >> ** RegBankSelect ** >> >> - Core logic is present, no optimizations yet, or more accurately, the >> greedy mode is still pretty silly. >> - TableGen support for RegisterBanks description. >> >> * What’s Left * >> >> - TableGen the instruction mapping from the existing SDISel patterns. >> - Improve the optimization heuristic. >> >> >> ** InstructionSelect ** >> >> - Core logic present. >> - TableGen support for simple SDISel patterns (i.e., GISel reuses SDISel >> patterns) >> >> * What’s Left * >> >> - Teach TableGen how to reuse more complex patterns: >> — Patterns with combines in them (e.g., (mull (add)) => madd) >> — Patterns with complex patterns (e.g., SelectAddressModXR0) >> >> >> *** On Going Work *** >> >> - General approach: use AArch64 O0 on the LLVM test suite as a driving >> vehicle to guide what to support next in the various passes. >> - Extend TableGen support to reuse more and more SDISel patterns. >> - ARM port. >> - AMDGPU port. >> - X86 port. >> >> If you have questions, don’t hesitate! >> >> Cheers, >> -Quentin >> >> _______________________________________________ >> LLVM Developers mailing list >> llvm-dev at lists.llvm.org >> http://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/20170121/9cdef3ff/attachment.html>
Hi, They made a documentation in that direction, this is still on going progress and we try to keep it current: http://llvm.org/docs/GlobalISel.html <http://llvm.org/docs/GlobalISel.html> We plan to do a guide for targeting GISel, but we want the framework to settle a bit before starting to write that down. Don’t hesitate to ask question around. Cheers, -Quentin> On Jan 21, 2017, at 2:37 AM, Nemanja Ivanovic <nemanja.i.ibm at gmail.com> wrote: > > Quentin, do you have some links you can share for guidance for those that might want to jump in to start preparing other targets for Global ISEL? > > On Sat, Jan 21, 2017 at 2:19 AM, Quentin Colombet via llvm-dev <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: > Hi all, > > Following the thread from http://lists.llvm.org/pipermail/llvm-dev/2017-January/109029.html <http://lists.llvm.org/pipermail/llvm-dev/2017-January/109029.html>, I am sending this email to give a status on GlobalISel progress and situation. > > We are pushing GlobalISel from the state of prototype to a production quality framework. We welcome help with patches, reviews, feedbacks and so on. > > As explained during the last developer meeting, we are aiming at enabling GISel by default for AArch64 at -O0 for this year (See http://llvm.org/devmtg/2016-11/#talk16 <http://llvm.org/devmtg/2016-11/#talk16>). > > Note: That does not mean the design is settle nor that we won’t change the APIs. > Note: A lot of the things listed in this email is a reminder of what we said during the dev meeting talk. > > *** High Level View *** > > As of r292481, we compile and run correctly with GISel (without fall back to SDISel) 63% of the LLVM test suite. If you are interested in detailed numbers, please see the attachments (courtesy of Kristof Beyls). > > Note: The compile time numbers are probably noisy (compiled in parallel on the same machine), and not relevant at this point of the project anyway. > > > *** Per Pass Status *** > > ** IRTranslator ** > > Mostly done. > > * What’s Left? * > > Some instructions are not yet supported. > > > ** Legalizer ** > > Core logic is present. > > * What’s Left? * > > - A lot of instructions are missing, in particular the vector ones. > - Legalization of G_SEQUENCE/G_EXTRACT still up in the air for complex cases. > > Note: The lack of broad vector support is one on the reason we target O0, i.e., the vectorizer doesn’t run and we are less likely to hit the missing implementation. > > > ** RegBankSelect ** > > - Core logic is present, no optimizations yet, or more accurately, the greedy mode is still pretty silly. > - TableGen support for RegisterBanks description. > > * What’s Left * > > - TableGen the instruction mapping from the existing SDISel patterns. > - Improve the optimization heuristic. > > > ** InstructionSelect ** > > - Core logic present. > - TableGen support for simple SDISel patterns (i.e., GISel reuses SDISel patterns) > > * What’s Left * > > - Teach TableGen how to reuse more complex patterns: > — Patterns with combines in them (e.g., (mull (add)) => madd) > — Patterns with complex patterns (e.g., SelectAddressModXR0) > > > *** On Going Work *** > > - General approach: use AArch64 O0 on the LLVM test suite as a driving vehicle to guide what to support next in the various passes. > - Extend TableGen support to reuse more and more SDISel patterns. > - ARM port. > - AMDGPU port. > - X86 port. > > If you have questions, don’t hesitate! > > Cheers, > -Quentin > > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org> > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev <http://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/20170123/18c16c4b/attachment.html>
Hi Sean,> On Jan 21, 2017, at 11:19 PM, Sean Silva <chisophugis at gmail.com> wrote: > > Hi Quentin, > > My understanding is that throughout the GISel lowering process all the lowering steps use the same underlying MI representation, but have different invariants at different points in time (for example, G_ opcodes may be present at some point but it would be an "assert" failure to see them at other points). Are there currently any plans (or things already implemented) to verify that these invariants hold at different points throughout the lowering pipeline?Yes, right now, the related invariants are checked at the beginning of each GISel core pass. Long-term the checks will be moved into the machine verifier but right now, given GISel is an optional library, we can’t move those checks, unless we put ifdef… which we want to avoid.> Also, in order to run passes in isolation, ideally they would have nice, easily-understandable failure modes if you feed them MIR with invariants they don't expect.This is expressed via some properties on the MachineFunction (property that should be dynamically computed ideally, but are not for now). We have isLegalized, isRegBankSelected, and so on. If you run a pass on a function that doesn’t have the right property, the machine verifier will complain about it (with something along the line of expected property blabla).> > The reason I bring this up is that at work I'm currently working on a compiler (not llvm-based) which does its lowering on a single IR and this is one of the most consistent pain points. In LLVM we already have this problem in the form of e.g. pre-RA and post-RA MI, but it seems like GISel is going to magnify this significantly.Let us know if you see cases where this is not going to be enough or see ways to improve this. Cheers, -Quentin> > > -- Sean Silva > > On Fri, Jan 20, 2017 at 5:19 PM, Quentin Colombet via llvm-dev <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: > Hi all, > > Following the thread from http://lists.llvm.org/pipermail/llvm-dev/2017-January/109029.html <http://lists.llvm.org/pipermail/llvm-dev/2017-January/109029.html>, I am sending this email to give a status on GlobalISel progress and situation. > > We are pushing GlobalISel from the state of prototype to a production quality framework. We welcome help with patches, reviews, feedbacks and so on. > > As explained during the last developer meeting, we are aiming at enabling GISel by default for AArch64 at -O0 for this year (See http://llvm.org/devmtg/2016-11/#talk16 <http://llvm.org/devmtg/2016-11/#talk16>). > > Note: That does not mean the design is settle nor that we won’t change the APIs. > Note: A lot of the things listed in this email is a reminder of what we said during the dev meeting talk. > > *** High Level View *** > > As of r292481, we compile and run correctly with GISel (without fall back to SDISel) 63% of the LLVM test suite. If you are interested in detailed numbers, please see the attachments (courtesy of Kristof Beyls). > > Note: The compile time numbers are probably noisy (compiled in parallel on the same machine), and not relevant at this point of the project anyway. > > > *** Per Pass Status *** > > ** IRTranslator ** > > Mostly done. > > * What’s Left? * > > Some instructions are not yet supported. > > > ** Legalizer ** > > Core logic is present. > > * What’s Left? * > > - A lot of instructions are missing, in particular the vector ones. > - Legalization of G_SEQUENCE/G_EXTRACT still up in the air for complex cases. > > Note: The lack of broad vector support is one on the reason we target O0, i.e., the vectorizer doesn’t run and we are less likely to hit the missing implementation. > > > ** RegBankSelect ** > > - Core logic is present, no optimizations yet, or more accurately, the greedy mode is still pretty silly. > - TableGen support for RegisterBanks description. > > * What’s Left * > > - TableGen the instruction mapping from the existing SDISel patterns. > - Improve the optimization heuristic. > > > ** InstructionSelect ** > > - Core logic present. > - TableGen support for simple SDISel patterns (i.e., GISel reuses SDISel patterns) > > * What’s Left * > > - Teach TableGen how to reuse more complex patterns: > — Patterns with combines in them (e.g., (mull (add)) => madd) > — Patterns with complex patterns (e.g., SelectAddressModXR0) > > > *** On Going Work *** > > - General approach: use AArch64 O0 on the LLVM test suite as a driving vehicle to guide what to support next in the various passes. > - Extend TableGen support to reuse more and more SDISel patterns. > - ARM port. > - AMDGPU port. > - X86 port. > > If you have questions, don’t hesitate! > > Cheers, > -Quentin > > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org> > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev <http://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/20170123/ba7c9618/attachment.html>
Hi all, We’ve been discussing offline some important points that I believe are useful to clarify on the mailing list as well, so here they are! *** What do we need to complete so we can declare GISel “production quality"? "Default ISel in O0”? *** First, we are going to add O0 bots to make sure we catch the problem sas early as possible. We actually already have such bots internally. From our perspective, we won’t suggest to flip the switch until we successfully hit those milestones: - LLVM test suite + external - Self host + test-suite again - Internal test cases - World build Moreover, we acknowledge that the LLVM test-suite and `make check` are not good enough to test the coverage of a new ISel. Therefore, as we bring up GISel, we also push on the infrastructure to improve the testing story. In particular, we are working on: - Tests generated from the tablegen inputs - Fuzzer for instruction selection - Better and more unit tests Second the switch to have GISel being the default ISel at O0 is an ongoing discussion with the community, we won’t make that decision alone! Moreover, we would like to get help and feedback from the following communities/users to make sure we cover as much use cases as possible upfront: A. FreeBSD B. Linux (both Debian and OpenMandriva) C. Android D. Chromium I don’t want to put words in Renato’s mouth, but my understanding is he’s going to help to get the right people in those communities involved. Finally, for the first year of living on GISel at O0, we plan to keep the fallback path to SDISel. That won’t help us with miscompile, but that will ensure we don’t abort on missing coverage if any. We see all those miscompile/crashes as showstopper and will actively working on fixing them. The bottom line is please play with GISel and file PRs for the cases that are interesting to you and don't work. Note: We are not in that code quality yet (right now we are in a coverage/correctness focus), but we aim at generating the same code quality as SDISel. When we switch to this “code quality” focus, we will want your feedback on that too! *** How to avoid Global ISel being a replacement for just Fast ISel? *** Given we aim at replacing O0 at first, you might be worried that GISel is going to be a FastISel only replacement. This is clearly not the goal. We are actually working towards the O1/O2/O3 replacement as well in parallel, hence all the work that you may have noticed regarding reusing the existing SDISel patterns in GISel. The reason we are not making any claims is that we don’t know what the timeline is going to look like. *** How do we make sure the experience for debugging remains as good as what SDISel/FastISel were offering? *** O0 is important to debugging code and we need to account for that in GISel as well. For this part, we involved and rely on our debug experts to do the testing. In particular Adrian is working on a Dwarf verifier IIRC that we are going to use to check that the generated debug info are in line with the previous ISels. Obviously this part of the project will benefit from all the help we can get. Kristof (Beyls) is also going to work with their gdb and DS-5 debug experts on the testing. The main issue really is that we don’t think anyone has an idea on what a good infrastructure should be for this problem. If you plan to help or have ideas on any of those points, let me know. Thanks, -Quentin> On Jan 20, 2017, at 5:19 PM, Quentin Colombet via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Hi all, > > Following the thread from http://lists.llvm.org/pipermail/llvm-dev/2017-January/109029.html, I am sending this email to give a status on GlobalISel progress and situation. > > We are pushing GlobalISel from the state of prototype to a production quality framework. We welcome help with patches, reviews, feedbacks and so on. > > As explained during the last developer meeting, we are aiming at enabling GISel by default for AArch64 at -O0 for this year (See http://llvm.org/devmtg/2016-11/#talk16). > > Note: That does not mean the design is settle nor that we won’t change the APIs. > Note: A lot of the things listed in this email is a reminder of what we said during the dev meeting talk. > > *** High Level View *** > > As of r292481, we compile and run correctly with GISel (without fall back to SDISel) 63% of the LLVM test suite. If you are interested in detailed numbers, please see the attachments (courtesy of Kristof Beyls). > > Note: The compile time numbers are probably noisy (compiled in parallel on the same machine), and not relevant at this point of the project anyway. > > > *** Per Pass Status *** > > ** IRTranslator ** > > Mostly done. > > * What’s Left? * > > Some instructions are not yet supported. > > > ** Legalizer ** > > Core logic is present. > > * What’s Left? * > > - A lot of instructions are missing, in particular the vector ones. > - Legalization of G_SEQUENCE/G_EXTRACT still up in the air for complex cases. > > Note: The lack of broad vector support is one on the reason we target O0, i.e., the vectorizer doesn’t run and we are less likely to hit the missing implementation. > > > ** RegBankSelect ** > > - Core logic is present, no optimizations yet, or more accurately, the greedy mode is still pretty silly. > - TableGen support for RegisterBanks description. > > * What’s Left * > > - TableGen the instruction mapping from the existing SDISel patterns. > - Improve the optimization heuristic. > > > ** InstructionSelect ** > > - Core logic present. > - TableGen support for simple SDISel patterns (i.e., GISel reuses SDISel patterns) > > * What’s Left * > > - Teach TableGen how to reuse more complex patterns: > — Patterns with combines in them (e.g., (mull (add)) => madd) > — Patterns with complex patterns (e.g., SelectAddressModXR0) > > > *** On Going Work *** > > - General approach: use AArch64 O0 on the LLVM test suite as a driving vehicle to guide what to support next in the various passes. > - Extend TableGen support to reuse more and more SDISel patterns. > - ARM port. > - AMDGPU port. > - X86 port. > > If you have questions, don’t hesitate! > > Cheers, > -Quentin > <292481_gisel_testsuite_status.xlsx>_______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
Martin J. O'Riordan via llvm-dev
2017-Feb-13 19:40 UTC
[llvm-dev] [GlobalISel] Quick Status
Sorry, meant to include LLVM-Dev -----Original Message----- From: Martin J. O'Riordan [mailto:martin.oriordan at movidius.com] Sent: 13 February 2017 19:39 To: 'Quentin Colombet' <qcolombet at apple.com> Subject: RE: [llvm-dev] [GlobalISel] Quick Status This is one of the things we used to run into; not just '-O0', but '-O0 -g'. Now I always test with '-O0 -g'. Sometimes '-O0' changes scheduling (uncommon and unexpected), and DAG transformations (uncommon and unexpected), but with '-g' it also stresses the 'DebugLoc', Dwarf and CFI support (presumably PDB too?) which often breaks things, especially in a VLIW machine. Can I recommend that when you are constructing your '-O0' bots, that you add '-g' too? '-O0' on its own is almost useless, and it is most commonly used in conjunction with '-g'. If the bots are green at '-O0 -g' there is a pretty good chance they will be green at '-O0' too. MartinO -----Original Message----- From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] On Behalf Of Quentin Colombet via llvm-dev Sent: 13 February 2017 16:23 To: Quentin Colombet <qcolombet at apple.com> Cc: llvm-dev <llvm-dev at lists.llvm.org> Subject: Re: [llvm-dev] [GlobalISel] Quick Status Hi all, We’ve been discussing offline some important points that I believe are useful to clarify on the mailing list as well, so here they are! *** What do we need to complete so we can declare GISel “production quality"? "Default ISel in O0”? *** First, we are going to add O0 bots to make sure we catch the problem sas early as possible. We actually already have such bots internally.>From our perspective, we won’t suggest to flip the switch until we successfully hit those milestones:- LLVM test suite + external - Self host + test-suite again - Internal test cases - World build Moreover, we acknowledge that the LLVM test-suite and `make check` are not good enough to test the coverage of a new ISel. Therefore, as we bring up GISel, we also push on the infrastructure to improve the testing story. In particular, we are working on: - Tests generated from the tablegen inputs - Fuzzer for instruction selection - Better and more unit tests Second the switch to have GISel being the default ISel at O0 is an ongoing discussion with the community, we won’t make that decision alone! Moreover, we would like to get help and feedback from the following communities/users to make sure we cover as much use cases as possible upfront: A. FreeBSD B. Linux (both Debian and OpenMandriva) C. Android D. Chromium I don’t want to put words in Renato’s mouth, but my understanding is he’s going to help to get the right people in those communities involved. Finally, for the first year of living on GISel at O0, we plan to keep the fallback path to SDISel. That won’t help us with miscompile, but that will ensure we don’t abort on missing coverage if any. We see all those miscompile/crashes as showstopper and will actively working on fixing them. The bottom line is please play with GISel and file PRs for the cases that are interesting to you and don't work. Note: We are not in that code quality yet (right now we are in a coverage/correctness focus), but we aim at generating the same code quality as SDISel. When we switch to this “code quality” focus, we will want your feedback on that too! *** How to avoid Global ISel being a replacement for just Fast ISel? *** Given we aim at replacing O0 at first, you might be worried that GISel is going to be a FastISel only replacement. This is clearly not the goal. We are actually working towards the O1/O2/O3 replacement as well in parallel, hence all the work that you may have noticed regarding reusing the existing SDISel patterns in GISel. The reason we are not making any claims is that we don’t know what the timeline is going to look like. *** How do we make sure the experience for debugging remains as good as what SDISel/FastISel were offering? *** O0 is important to debugging code and we need to account for that in GISel as well. For this part, we involved and rely on our debug experts to do the testing. In particular Adrian is working on a Dwarf verifier IIRC that we are going to use to check that the generated debug info are in line with the previous ISels. Obviously this part of the project will benefit from all the help we can get. Kristof (Beyls) is also going to work with their gdb and DS-5 debug experts on the testing. The main issue really is that we don’t think anyone has an idea on what a good infrastructure should be for this problem. If you plan to help or have ideas on any of those points, let me know. Thanks, -Quentin> On Jan 20, 2017, at 5:19 PM, Quentin Colombet via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Hi all, > > Following the thread from http://lists.llvm.org/pipermail/llvm-dev/2017-January/109029.html, I am sending this email to give a status on GlobalISel progress and situation. > > We are pushing GlobalISel from the state of prototype to a production quality framework. We welcome help with patches, reviews, feedbacks and so on. > > As explained during the last developer meeting, we are aiming at enabling GISel by default for AArch64 at -O0 for this year (See http://llvm.org/devmtg/2016-11/#talk16). > > Note: That does not mean the design is settle nor that we won’t change the APIs. > Note: A lot of the things listed in this email is a reminder of what we said during the dev meeting talk. > > *** High Level View *** > > As of r292481, we compile and run correctly with GISel (without fall back to SDISel) 63% of the LLVM test suite. If you are interested in detailed numbers, please see the attachments (courtesy of Kristof Beyls). > > Note: The compile time numbers are probably noisy (compiled in parallel on the same machine), and not relevant at this point of the project anyway. > > > *** Per Pass Status *** > > ** IRTranslator ** > > Mostly done. > > * What’s Left? * > > Some instructions are not yet supported. > > > ** Legalizer ** > > Core logic is present. > > * What’s Left? * > > - A lot of instructions are missing, in particular the vector ones. > - Legalization of G_SEQUENCE/G_EXTRACT still up in the air for complex cases. > > Note: The lack of broad vector support is one on the reason we target O0, i.e., the vectorizer doesn’t run and we are less likely to hit the missing implementation. > > > ** RegBankSelect ** > > - Core logic is present, no optimizations yet, or more accurately, the greedy mode is still pretty silly. > - TableGen support for RegisterBanks description. > > * What’s Left * > > - TableGen the instruction mapping from the existing SDISel patterns. > - Improve the optimization heuristic. > > > ** InstructionSelect ** > > - Core logic present. > - TableGen support for simple SDISel patterns (i.e., GISel reuses > SDISel patterns) > > * What’s Left * > > - Teach TableGen how to reuse more complex patterns: > — Patterns with combines in them (e.g., (mull (add)) => madd) — > Patterns with complex patterns (e.g., SelectAddressModXR0) > > > *** On Going Work *** > > - General approach: use AArch64 O0 on the LLVM test suite as a driving vehicle to guide what to support next in the various passes. > - Extend TableGen support to reuse more and more SDISel patterns. > - ARM port. > - AMDGPU port. > - X86 port. > > If you have questions, don’t hesitate! > > Cheers, > -Quentin > <292481_gisel_testsuite_status.xlsx>__________________________________ > _____________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev_______________________________________________ LLVM Developers mailing list llvm-dev at lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
Hi Quentin, Thanks for the summary. I will indeed do my best to get the wider community together. Some of the people there are already volunteering, so we should be fine. Cheers, Renato On 13 Feb 2017 16:23, "Quentin Colombet" <qcolombet at apple.com> wrote:> Hi all, > > We’ve been discussing offline some important points that I believe are > useful to clarify on the mailing list as well, so here they are! > > > *** What do we need to complete so we can declare GISel “production > quality"? "Default ISel in O0”? *** > > First, we are going to add O0 bots to make sure we catch the problem sas > early as possible. We actually already have such bots internally. > > From our perspective, we won’t suggest to flip the switch until we > successfully hit those milestones: > - LLVM test suite + external > - Self host + test-suite again > - Internal test cases > - World build > > Moreover, we acknowledge that the LLVM test-suite and `make check` are not > good enough to test the coverage of a new ISel. Therefore, as we bring up > GISel, we also push on the infrastructure to improve the testing story. > In particular, we are working on: > - Tests generated from the tablegen inputs > - Fuzzer for instruction selection > - Better and more unit tests > > Second the switch to have GISel being the default ISel at O0 is an ongoing > discussion with the community, we won’t make that decision alone! > > Moreover, we would like to get help and feedback from the following > communities/users to make sure we cover as much use cases as possible > upfront: > A. FreeBSD > B. Linux (both Debian and OpenMandriva) > C. Android > D. Chromium > > I don’t want to put words in Renato’s mouth, but my understanding is he’s > going to help to get the right people in those communities involved. > > Finally, for the first year of living on GISel at O0, we plan to keep the > fallback path to SDISel. That won’t help us with miscompile, but that will > ensure we don’t abort on missing coverage if any. We see all those > miscompile/crashes as showstopper and will actively working on fixing them. > > The bottom line is please play with GISel and file PRs for the cases that > are interesting to you and don't work. > Note: We are not in that code quality yet (right now we are in a > coverage/correctness focus), but we aim at generating the same code quality > as SDISel. When we switch to this “code quality” focus, we will want your > feedback on that too! > > > *** How to avoid Global ISel being a replacement for just Fast ISel? *** > > Given we aim at replacing O0 at first, you might be worried that GISel is > going to be a FastISel only replacement. This is clearly not the goal. > > We are actually working towards the O1/O2/O3 replacement as well in > parallel, hence all the work that you may have noticed regarding reusing > the existing SDISel patterns in GISel. The reason we are not making any > claims is that we don’t know what the timeline is going to look like. > > > *** How do we make sure the experience for debugging remains as good as > what SDISel/FastISel were offering? *** > > O0 is important to debugging code and we need to account for that in GISel > as well. > > For this part, we involved and rely on our debug experts to do the > testing. In particular Adrian is working on a Dwarf verifier IIRC that we > are going to use to check that the generated debug info are in line with > the previous ISels. > > Obviously this part of the project will benefit from all the help we can > get. Kristof (Beyls) is also going to work with their gdb and DS-5 debug > experts on the testing. > > The main issue really is that we don’t think anyone has an idea on what a > good infrastructure should be for this problem. > > > If you plan to help or have ideas on any of those points, let me know. > > Thanks, > -Quentin > > > > On Jan 20, 2017, at 5:19 PM, Quentin Colombet via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > > > > Hi all, > > > > Following the thread from http://lists.llvm.org/pipermail/llvm-dev/2017- > January/109029.html, I am sending this email to give a status on > GlobalISel progress and situation. > > > > We are pushing GlobalISel from the state of prototype to a production > quality framework. We welcome help with patches, reviews, feedbacks and so > on. > > > > As explained during the last developer meeting, we are aiming at > enabling GISel by default for AArch64 at -O0 for this year (See > http://llvm.org/devmtg/2016-11/#talk16). > > > > Note: That does not mean the design is settle nor that we won’t change > the APIs. > > Note: A lot of the things listed in this email is a reminder of what we > said during the dev meeting talk. > > > > *** High Level View *** > > > > As of r292481, we compile and run correctly with GISel (without fall > back to SDISel) 63% of the LLVM test suite. If you are interested in > detailed numbers, please see the attachments (courtesy of Kristof Beyls). > > > > Note: The compile time numbers are probably noisy (compiled in parallel > on the same machine), and not relevant at this point of the project anyway. > > > > > > *** Per Pass Status *** > > > > ** IRTranslator ** > > > > Mostly done. > > > > * What’s Left? * > > > > Some instructions are not yet supported. > > > > > > ** Legalizer ** > > > > Core logic is present. > > > > * What’s Left? * > > > > - A lot of instructions are missing, in particular the vector ones. > > - Legalization of G_SEQUENCE/G_EXTRACT still up in the air for complex > cases. > > > > Note: The lack of broad vector support is one on the reason we target > O0, i.e., the vectorizer doesn’t run and we are less likely to hit the > missing implementation. > > > > > > ** RegBankSelect ** > > > > - Core logic is present, no optimizations yet, or more accurately, the > greedy mode is still pretty silly. > > - TableGen support for RegisterBanks description. > > > > * What’s Left * > > > > - TableGen the instruction mapping from the existing SDISel patterns. > > - Improve the optimization heuristic. > > > > > > ** InstructionSelect ** > > > > - Core logic present. > > - TableGen support for simple SDISel patterns (i.e., GISel reuses SDISel > patterns) > > > > * What’s Left * > > > > - Teach TableGen how to reuse more complex patterns: > > — Patterns with combines in them (e.g., (mull (add)) => madd) > > — Patterns with complex patterns (e.g., SelectAddressModXR0) > > > > > > *** On Going Work *** > > > > - General approach: use AArch64 O0 on the LLVM test suite as a driving > vehicle to guide what to support next in the various passes. > > - Extend TableGen support to reuse more and more SDISel patterns. > > - ARM port. > > - AMDGPU port. > > - X86 port. > > > > If you have questions, don’t hesitate! > > > > Cheers, > > -Quentin > > <292481_gisel_testsuite_status.xlsx>__________________ > _____________________________ > > LLVM Developers mailing list > > llvm-dev at lists.llvm.org > > http://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/20170213/8c42c964/attachment.html>
+llvm-dev Thanks Khem.> On Feb 13, 2017, at 3:14 PM, Khem Raj <raj.khem at gmail.com> wrote: > > hi Quentin > > On 2/13/17 8:23 AM, Quentin Colombet via llvm-dev wrote: >> Moreover, we would like to get help and feedback from the following communities/users to make sure we cover as much use cases as possible upfront: >> A. FreeBSD >> B. Linux (both Debian and OpenMandriva) > > Please add Yocto/OpenEmbedded for Embedded Linux support, to this list > as well. We are building clang based cross compilers (as an additional > option) for arm/mips/ppc/x86 for 32bit and 64bit targets using glibc and > musl based C libs.Do you think you would have time to test this when the time come?> > https://github.com/kraj/meta-clang > > We currently are using release_4.0 branch > > >> C. Android >> D. Chromium >>
On 2/13/17 3:30 PM, Quentin Colombet wrote:> +llvm-dev > > Thanks Khem. > >> On Feb 13, 2017, at 3:14 PM, Khem Raj <raj.khem at gmail.com> wrote: >> >> hi Quentin >> >> On 2/13/17 8:23 AM, Quentin Colombet via llvm-dev wrote: >>> Moreover, we would like to get help and feedback from the following communities/users to make sure we cover as much use cases as possible upfront: >>> A. FreeBSD >>> B. Linux (both Debian and OpenMandriva) >> >> Please add Yocto/OpenEmbedded for Embedded Linux support, to this list >> as well. We are building clang based cross compilers (as an additional >> option) for arm/mips/ppc/x86 for 32bit and 64bit targets using glibc and >> musl based C libs. > > Do you think you would have time to test this when the time come?Not all combinations. However, some combinations eg. rpi3 ( musl and glibc ) I will test.> > >> >> https://github.com/kraj/meta-clang >> >> We currently are using release_4.0 branch >> >> >>> C. Android >>> D. Chromium >>> >
The current code generator based on SelectionDAG has two different concepts: DAG node combining and instruction selection. Will the code generator based on GlobalISel have this distinction as well? On 2017-01-21 02:19, Quentin Colombet via llvm-dev wrote:> Hi all, > > Following the thread from > http://lists.llvm.org/pipermail/llvm-dev/2017-January/109029.html, I > am sending this email to give a status on GlobalISel progress and > situation. > > We are pushing GlobalISel from the state of prototype to a production > quality framework. We welcome help with patches, reviews, feedbacks > and so on. > > As explained during the last developer meeting, we are aiming at > enabling GISel by default for AArch64 at -O0 for this year (See > http://llvm.org/devmtg/2016-11/#talk16). > > Note: That does not mean the design is settle nor that we won’t change > the APIs. > Note: A lot of the things listed in this email is a reminder of what > we said during the dev meeting talk. > > *** High Level View *** > > As of r292481, we compile and run correctly with GISel (without fall > back to SDISel) 63% of the LLVM test suite. If you are interested in > detailed numbers, please see the attachments (courtesy of Kristof > Beyls). > > Note: The compile time numbers are probably noisy (compiled in > parallel on the same machine), and not relevant at this point of the > project anyway. > > > *** Per Pass Status *** > > ** IRTranslator ** > > Mostly done. > > * What’s Left? * > > Some instructions are not yet supported. > > > ** Legalizer ** > > Core logic is present. > > * What’s Left? * > > - A lot of instructions are missing, in particular the vector ones. > - Legalization of G_SEQUENCE/G_EXTRACT still up in the air for complex > cases. > > Note: The lack of broad vector support is one on the reason we target > O0, i.e., the vectorizer doesn’t run and we are less likely to hit the > missing implementation. > > > ** RegBankSelect ** > > - Core logic is present, no optimizations yet, or more accurately, the > greedy mode is still pretty silly. > - TableGen support for RegisterBanks description. > > * What’s Left * > > - TableGen the instruction mapping from the existing SDISel patterns. > - Improve the optimization heuristic. > > > ** InstructionSelect ** > > - Core logic present. > - TableGen support for simple SDISel patterns (i.e., GISel reuses > SDISel patterns) > > * What’s Left * > > - Teach TableGen how to reuse more complex patterns: > — Patterns with combines in them (e.g., (mull (add)) => madd) > — Patterns with complex patterns (e.g., SelectAddressModXR0) > > > *** On Going Work *** > > - General approach: use AArch64 O0 on the LLVM test suite as a driving > vehicle to guide what to support next in the various passes. > - Extend TableGen support to reuse more and more SDISel patterns. > - ARM port. > - AMDGPU port. > - X86 port. > > If you have questions, don’t hesitate! > > Cheers, > -Quentin > > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
Hi Manuel,> On Feb 15, 2017, at 2:15 PM, Manuel Jacob <me at manueljacob.de> wrote: > > The current code generator based on SelectionDAG has two different concepts: DAG node combining and instruction selection. > > Will the code generator based on GlobalISel have this distinction as well?Short answer, yes. GlobalISel per se does not come with combining capabilities. It provides an instruction selection framework and you can hook up any passes you want anywhere in the pipeline, in particular to do combines. Combine/folding are supported when selecting the instructions but right now, GlobalISel does not come with an equivalent of DAG combine. We are going to add generic support for that in the future but the core pipeline shouldn’t require it for correctness. Note: We may leverage the existing MachineCombiner for that. Cheers, -Quentin> > On 2017-01-21 02:19, Quentin Colombet via llvm-dev wrote: >> Hi all, >> Following the thread from >> http://lists.llvm.org/pipermail/llvm-dev/2017-January/109029.html, I >> am sending this email to give a status on GlobalISel progress and >> situation. >> We are pushing GlobalISel from the state of prototype to a production >> quality framework. We welcome help with patches, reviews, feedbacks >> and so on. >> As explained during the last developer meeting, we are aiming at >> enabling GISel by default for AArch64 at -O0 for this year (See >> http://llvm.org/devmtg/2016-11/#talk16). >> Note: That does not mean the design is settle nor that we won’t change the APIs. >> Note: A lot of the things listed in this email is a reminder of what >> we said during the dev meeting talk. >> *** High Level View *** >> As of r292481, we compile and run correctly with GISel (without fall >> back to SDISel) 63% of the LLVM test suite. If you are interested in >> detailed numbers, please see the attachments (courtesy of Kristof >> Beyls). >> Note: The compile time numbers are probably noisy (compiled in >> parallel on the same machine), and not relevant at this point of the >> project anyway. >> *** Per Pass Status *** >> ** IRTranslator ** >> Mostly done. >> * What’s Left? * >> Some instructions are not yet supported. >> ** Legalizer ** >> Core logic is present. >> * What’s Left? * >> - A lot of instructions are missing, in particular the vector ones. >> - Legalization of G_SEQUENCE/G_EXTRACT still up in the air for complex cases. >> Note: The lack of broad vector support is one on the reason we target >> O0, i.e., the vectorizer doesn’t run and we are less likely to hit the >> missing implementation. >> ** RegBankSelect ** >> - Core logic is present, no optimizations yet, or more accurately, the >> greedy mode is still pretty silly. >> - TableGen support for RegisterBanks description. >> * What’s Left * >> - TableGen the instruction mapping from the existing SDISel patterns. >> - Improve the optimization heuristic. >> ** InstructionSelect ** >> - Core logic present. >> - TableGen support for simple SDISel patterns (i.e., GISel reuses >> SDISel patterns) >> * What’s Left * >> - Teach TableGen how to reuse more complex patterns: >> — Patterns with combines in them (e.g., (mull (add)) => madd) >> — Patterns with complex patterns (e.g., SelectAddressModXR0) >> *** On Going Work *** >> - General approach: use AArch64 O0 on the LLVM test suite as a driving >> vehicle to guide what to support next in the various passes. >> - Extend TableGen support to reuse more and more SDISel patterns. >> - ARM port. >> - AMDGPU port. >> - X86 port. >> If you have questions, don’t hesitate! >> Cheers, >> -Quentin >> _______________________________________________ >> LLVM Developers mailing list >> llvm-dev at lists.llvm.org >> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev