Greg Bedwell via llvm-dev
2019-Jul-24 10:41 UTC
[llvm-dev] How to contribute on LLVM project as beginner
On Wed, 24 Jul 2019 at 10:52, Oliver Stannard via llvm-dev < llvm-dev at lists.llvm.org> wrote:> Your script looks OK, though you won't want to use the -opt-bisect-limit> option until you've found a case where code-generation changes. Instead, > that's a tool which you could use to narrow down the pass inside LLVM which > is causing the change. > > The problem is that your input code is far too simple to trigger any > interesting optimisations. I'd suggest starting with either some code from > the LLVM test suite (https://github.com/llvm/llvm-test-suite), or some > code generated by csmith (https://embed.cs.utah.edu/csmith/). The former > has the advantage of being (mostly) real code people actually write, and > the latter can generate a large amount of complex code without any external > dependencies (so it's easy to build). > >A few other things to note: There's a tool in clang here ( https://github.com/llvm/llvm-project/tree/master/clang/utils/check_cfc ) called check_cfc which uses the same basic idea as the script above. It's designed to transparently wrap clang invocations so that any differences in codegen will actually trigger a build failure. There are a few more details in these slides ( https://llvm.org/devmtg/2015-04/slides/Verifying_code_gen_dash_g_final.pdf ). Ultimately it doesn't matter which tools you use in order to find bugs, but you may find it useful. We've got a meta-bug here to which we've been attaching already-reported bugs in this area ( https://bugs.llvm.org/show_bug.cgi?id=37728 ) which might be a nice place to start so that you can try replicating the results. In particular https://bugs.llvm.org/show_bug.cgi?id=42138 is a bug that one of our interns found recently using the check_cfc script with llvm test-suite (and then reducing with creduce). Unfortunately it was right at the end of his internship so he didn't get a chance to try and fix it. It might be a good starting point to have a go at replicating the failure and then trying to figure out what's happening and fixing it (assuming that it's still present). I'm sure that there are plenty of people in the community willing to help out with any specific issues you run into along the way. Good luck, with whichever approach you take! -Greg -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20190724/1efa6881/attachment.html>
Neil Nelson via llvm-dev
2019-Aug-23 01:53 UTC
[llvm-dev] How to contribute on LLVM project as beginner
Built LLVM 8.0.1 for debug using -DCMAKE_EXPORT_COMPILE_COMMANDS=ON. Put together a sequence using clang/utils/check_cfc on the compile list using the same compile parameters except for the -g and -o options that check_cfc provides. 2506 files were successfully processed by check_cfc out of a total of 2833. Three was the maximum number of differences obtained with the possibly interesting types here. 4 of this type. - push + sh %r - mov + v %r - sub + b $0 3 of this type. - pq 66 + v -0 - v -0 + v %r - v %r + llq 6d 1 each of these types. - pq ef + pq ea - pq 68 + a -0 - a -0 + llq 6c - pq 3a + vb $0 - vb $0 + a -0 - a -0 + v %r - jmpq + mov - mov + and - and + mov Regards, Neil Nelson On 7/24/19 4:41 AM, Greg Bedwell via llvm-dev wrote:> > > On Wed, 24 Jul 2019 at 10:52, Oliver Stannard via llvm-dev > <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: > > Your script looks OK, though you won't want to use > the -opt-bisect-limit= option until you've found a case where > code-generation changes. Instead, that's a tool which you could > use to narrow down the pass inside LLVM which is causing the change. > > The problem is that your input code is far too simple to trigger > any interesting optimisations. I'd suggest starting with either > some code from the LLVM test suite > (https://github.com/llvm/llvm-test-suite), or some code generated > by csmith (https://embed.cs.utah.edu/csmith/). The former has the > advantage of being (mostly) real code people actually write, and > the latter can generate a large amount of complex code without any > external dependencies (so it's easy to build). > > > A few other things to note: > > There's a tool in clang here ( > https://github.com/llvm/llvm-project/tree/master/clang/utils/check_cfc ) > called check_cfc which uses the same basic idea as the script above. > It's designed to transparently wrap clang invocations so that any > differences in codegen will actually trigger a build failure. There > are a few more details in these slides ( > https://llvm.org/devmtg/2015-04/slides/Verifying_code_gen_dash_g_final.pdf ). > Ultimately it doesn't matter which tools you use in order to find > bugs, but you may find it useful. > > We've got a meta-bug here to which we've been attaching > already-reported bugs in this area ( > https://bugs.llvm.org/show_bug.cgi?id=37728 ) which might be a nice > place to start so that you can try replicating the results. In > particular https://bugs.llvm.org/show_bug.cgi?id=42138 is a bug that > one of our interns found recently using the check_cfc script with llvm > test-suite (and then reducing with creduce). Unfortunately it was > right at the end of his internship so he didn't get a chance to try > and fix it. It might be a good starting point to have a go at > replicating the failure and then trying to figure out what's happening > and fixing it (assuming that it's still present). I'm sure that there > are plenty of people in the community willing to help out with any > specific issues you run into along the way. > > Good luck, with whichever approach you take! > > -Greg > > > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20190822/da32bfb5/attachment-0001.html>
via llvm-dev
2019-Aug-23 12:33 UTC
[llvm-dev] How to contribute on LLVM project as beginner
Nice work! Are you planning to track down where these differences come from, or do you plan to file bugs for them? --paulr From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] On Behalf Of Neil Nelson via llvm-dev Sent: Thursday, August 22, 2019 9:53 PM To: llvm-dev at lists.llvm.org Subject: Re: [llvm-dev] How to contribute on LLVM project as beginner Built LLVM 8.0.1 for debug using -DCMAKE_EXPORT_COMPILE_COMMANDS=ON. Put together a sequence using clang/utils/check_cfc on the compile list using the same compile parameters except for the -g and -o options that check_cfc provides. 2506 files were successfully processed by check_cfc out of a total of 2833. Three was the maximum number of differences obtained with the possibly interesting types here. 4 of this type. - push + sh %r - mov + v %r - sub + b $0 3 of this type. - pq 66 + v -0 - v -0 + v %r - v %r + llq 6d 1 each of these types. - pq ef + pq ea - pq 68 + a -0 - a -0 + llq 6c - pq 3a + vb $0 - vb $0 + a -0 - a -0 + v %r - jmpq + mov - mov + and - and + mov Regards, Neil Nelson On 7/24/19 4:41 AM, Greg Bedwell via llvm-dev wrote: On Wed, 24 Jul 2019 at 10:52, Oliver Stannard via llvm-dev <llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org>> wrote: Your script looks OK, though you won't want to use the -opt-bisect-limit= option until you've found a case where code-generation changes. Instead, that's a tool which you could use to narrow down the pass inside LLVM which is causing the change. The problem is that your input code is far too simple to trigger any interesting optimisations. I'd suggest starting with either some code from the LLVM test suite (https://github.com/llvm/llvm-test-suite), or some code generated by csmith (https://embed.cs.utah.edu/csmith/). The former has the advantage of being (mostly) real code people actually write, and the latter can generate a large amount of complex code without any external dependencies (so it's easy to build). A few other things to note: There's a tool in clang here ( https://github.com/llvm/llvm-project/tree/master/clang/utils/check_cfc ) called check_cfc which uses the same basic idea as the script above. It's designed to transparently wrap clang invocations so that any differences in codegen will actually trigger a build failure. There are a few more details in these slides ( https://llvm.org/devmtg/2015-04/slides/Verifying_code_gen_dash_g_final.pdf ). Ultimately it doesn't matter which tools you use in order to find bugs, but you may find it useful. We've got a meta-bug here to which we've been attaching already-reported bugs in this area ( https://bugs.llvm.org/show_bug.cgi?id=37728 ) which might be a nice place to start so that you can try replicating the results. In particular https://bugs.llvm.org/show_bug.cgi?id=42138 is a bug that one of our interns found recently using the check_cfc script with llvm test-suite (and then reducing with creduce). Unfortunately it was right at the end of his internship so he didn't get a chance to try and fix it. It might be a good starting point to have a go at replicating the failure and then trying to figure out what's happening and fixing it (assuming that it's still present). I'm sure that there are plenty of people in the community willing to help out with any specific issues you run into along the way. Good luck, with whichever approach you take! -Greg _______________________________________________ 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/20190823/47219522/attachment.html>