Hello, We have booked a couple of slots during EuroLLVM this year that we would like to dedicate to real hacking!!! Therefore, we would like to offer to the attendees this year an opportunity to escape from the presentation sessions and dive into fun coding to learn something new or to solve some interesting problems. The current proposal is to have 2 x 45 mins on Monday afternoon and 2 x 45 mins sessions on Tuesday morning.We will have rooms with Internet and paper boards provided. We can pre-setup everything before the start to make sure we are more productive and perhaps even do some little homework offline before we meet. For the success of this event the key is to find suitable topics that can be either: - novel enough; - useful to someone (doesn't have to be everyone); - interesting; - challenging; - addressing long standing issue; or a combination of those. Ideally, we would like to see suggestions from you in which at least some part should be doable within half day with multiple developers on board. However, we also accept topics that require more time to be developed but for which some good concept can be developed within a couple of hours brainstorming session. Below are some ideas that could be addressed: - Improve support for outside of tree users. LLVM and Clang both have a lot of users that don't contribute to the main repository. They are often in the domain of embedded and heterogeneous targets. The code is typically kept confidential in the propriety toolchains but some is also available open source. Can we do something to make LLVM more friendly with respect to those? - Improve modularity of features. Clang and LLVM support wide number of languages and targets. This results in multiple problems i.e. large compiler binary size, interference during the development. Could we make it more modular? - Invert the logic of convergent attribute in LLVM. While adding the attribute to OpenCL functions we discussed that the semantic of convergent attribute is currently not optimal https://clang.llvm.org/docs/AttributeReference.html#convergent-clang-convergent-clang-convergent. We could make it better by inverting the logic because we will provide a way to specify where compiler doesn't have to be conservative with respect to optimizations that change CFG. This will allow more optimizations to happen on the calls that can't be analyzed statically<https://reviews.llvm.org/D38113>. The details can be found in discussions on the review: https://reviews.llvm.org/D38113.<https://reviews.llvm.org/D38113> <https://reviews.llvm.org/D38113> - Evaluate/gather some useful analysis data. We can collect some useful information that can help us to improve the compiler. This can be for example analysis of code coverage by the tests or compilation time hotspots. - Address some bugs that otherwise don't get bandwidth allocated to them. If you like any idea above please vote for it! Do you have any other interesting idea to hack? We would like to hear about it! Cheers, Anastasia -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180316/61dc6df7/attachment.html>
Kim Gräsman via llvm-dev
2018-Mar-16 16:52 UTC
[llvm-dev] [cfe-dev] Hacking at EuroLLVM 2018
Hey Anastasia, all, There's a long-standing CMake issue with the Debian packaging for Clang (LLVM works), described here: https://bugs.debian.org/cgi-bin/bugreport.cgi?att=1;bug=862328 I've done some debugging and have a good idea of what should be done, I just don't know enough about Debian packaging details and testing to make much progress. I'd love to hack on this with someone who knows more about Debian packaging and CMake. This sounds like it could fall into "Improve support for outside of tree users", but it's also fairly specific and time-consuming and might work better with a separate crowd. I think "Fix CMake find provider for Clang Debian package" is a nice approximate title :) - Kim On Fri, Mar 16, 2018 at 4:15 PM, Anastasia Stulova via cfe-dev <cfe-dev at lists.llvm.org> wrote:> Hello, > > > We have booked a couple of slots during EuroLLVM this year that we would > like to dedicate to real hacking!!! Therefore, we would like to offer to the > attendees this year an opportunity to escape from the presentation sessions > and dive into fun coding to learn something new or to solve some interesting > problems. > > > The current proposal is to have 2 x 45 mins on Monday afternoon and 2 x 45 > mins sessions on Tuesday morning.We will have rooms with Internet and paper > boards provided. We can pre-setup everything before the start to make sure > we are more productive and perhaps even do some little homework offline > before we meet. > > > For the success of this event the key is to find suitable topics that can be > either: > > - novel enough; > > - useful to someone (doesn't have to be everyone); > > - interesting; > > - challenging; > > - addressing long standing issue; > > or a combination of those. > > > Ideally, we would like to see suggestions from you in which at least some > part should be doable within half day with multiple developers on board. > However, we also accept topics that require more time to be developed but > for which some good concept can be developed within a couple of hours > brainstorming session. > > > Below are some ideas that could be addressed: > > > - Improve support for outside of tree users. LLVM and Clang both have a lot > of users that don't contribute to the main repository. They are often in the > domain of embedded and heterogeneous targets. The code is typically kept > confidential in the propriety toolchains but some is also available open > source. Can we do something to make LLVM more friendly with respect to > those? > > > - Improve modularity of features. Clang and LLVM support wide number of > languages and targets. This results in multiple problems i.e. large > compiler binary size, interference during the development. Could we make it > more modular? > > > - Invert the logic of convergent attribute in LLVM. While adding the > attribute to OpenCL functions we discussed that the semantic of convergent > attribute is currently not optimal > https://clang.llvm.org/docs/AttributeReference.html#convergent-clang-convergent-clang-convergent. > We could make it better by inverting the logic because we will provide a way > to specify where compiler doesn't have to be conservative with respect to > optimizations that change CFG. This will allow more optimizations to happen > on the calls that can't be analyzed statically. The details can be found in > discussions on the review: https://reviews.llvm.org/D38113. > > > - Evaluate/gather some useful analysis data. We can collect some useful > information that can help us to improve the compiler. This can be for > example analysis of code coverage by the tests or compilation time hotspots. > > > - Address some bugs that otherwise don't get bandwidth allocated to them. > > > If you like any idea above please vote for it! Do you have any other > interesting idea to hack? We would like to hear about it! > > > Cheers, > > Anastasia > > > > > _______________________________________________ > cfe-dev mailing list > cfe-dev at lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev >
Anastasia Stulova via llvm-dev
2018-Mar-20 18:26 UTC
[llvm-dev] [cfe-dev] Hacking at EuroLLVM 2018
Hi Kim, Thanks. This looks like a well defined problem to hack. I will add it to the list. I hope there will be people with relevant experience or willing to improvise with you. 😊 Cheers, Anastasia ________________________________ From: Kim Gräsman <kim.grasman at gmail.com> Sent: 16 March 2018 16:52 To: Anastasia Stulova Cc: clang-dev developer list; llvm-dev at lists.llvm.org; nd Subject: Re: [cfe-dev] Hacking at EuroLLVM 2018 Hey Anastasia, all, There's a long-standing CMake issue with the Debian packaging for Clang (LLVM works), described here: https://bugs.debian.org/cgi-bin/bugreport.cgi?att=1;bug=862328 I've done some debugging and have a good idea of what should be done, I just don't know enough about Debian packaging details and testing to make much progress. I'd love to hack on this with someone who knows more about Debian packaging and CMake. This sounds like it could fall into "Improve support for outside of tree users", but it's also fairly specific and time-consuming and might work better with a separate crowd. I think "Fix CMake find provider for Clang Debian package" is a nice approximate title :) - Kim On Fri, Mar 16, 2018 at 4:15 PM, Anastasia Stulova via cfe-dev <cfe-dev at lists.llvm.org> wrote:> Hello, > > > We have booked a couple of slots during EuroLLVM this year that we would > like to dedicate to real hacking!!! Therefore, we would like to offer to the > attendees this year an opportunity to escape from the presentation sessions > and dive into fun coding to learn something new or to solve some interesting > problems. > > > The current proposal is to have 2 x 45 mins on Monday afternoon and 2 x 45 > mins sessions on Tuesday morning.We will have rooms with Internet and paper > boards provided. We can pre-setup everything before the start to make sure > we are more productive and perhaps even do some little homework offline > before we meet. > > > For the success of this event the key is to find suitable topics that can be > either: > > - novel enough; > > - useful to someone (doesn't have to be everyone); > > - interesting; > > - challenging; > > - addressing long standing issue; > > or a combination of those. > > > Ideally, we would like to see suggestions from you in which at least some > part should be doable within half day with multiple developers on board. > However, we also accept topics that require more time to be developed but > for which some good concept can be developed within a couple of hours > brainstorming session. > > > Below are some ideas that could be addressed: > > > - Improve support for outside of tree users. LLVM and Clang both have a lot > of users that don't contribute to the main repository. They are often in the > domain of embedded and heterogeneous targets. The code is typically kept > confidential in the propriety toolchains but some is also available open > source. Can we do something to make LLVM more friendly with respect to > those? > > > - Improve modularity of features. Clang and LLVM support wide number of > languages and targets. This results in multiple problems i.e. large > compiler binary size, interference during the development. Could we make it > more modular? > > > - Invert the logic of convergent attribute in LLVM. While adding the > attribute to OpenCL functions we discussed that the semantic of convergent > attribute is currently not optimal > https://clang.llvm.org/docs/AttributeReference.html#convergent-clang-convergent-clang-convergent. > We could make it better by inverting the logic because we will provide a way > to specify where compiler doesn't have to be conservative with respect to > optimizations that change CFG. This will allow more optimizations to happen > on the calls that can't be analyzed statically. The details can be found in > discussions on the review: https://reviews.llvm.org/D38113. > > > - Evaluate/gather some useful analysis data. We can collect some useful > information that can help us to improve the compiler. This can be for > example analysis of code coverage by the tests or compilation time hotspots. > > > - Address some bugs that otherwise don't get bandwidth allocated to them. > > > If you like any idea above please vote for it! Do you have any other > interesting idea to hack? We would like to hear about it! > > > Cheers, > > Anastasia > > > > > _______________________________________________ > cfe-dev mailing list > cfe-dev at lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180320/6ce9ef62/attachment.html>
Since less than a week is left to EuroLLVM, I would like to remind you about the Hacker Lab! You can find the time and location on the website: https://2018eurollvm.sched.com/ Note, we are still accepting the topics and the current list is as follows: - Improve support for outside of tree users. LLVM and Clang both have a lot of users that don't contribute to the main repository. They are often in the domain of embedded and heterogeneous targets. The code is typically kept confidential in the propriety toolchains but some is also available open source. Can we do something to make LLVM more friendly with respect to those? - Improve modularity of features. Clang and LLVM support wide number of languages and targets. This results in multiple problems i.e. large compiler binary size, interference during the development. Could we make it more modular? - Invert the logic of convergent attribute in LLVM. While adding the attribute to OpenCL functions we discussed that the semantic of convergent attribute is currently not optimal https://clang.llvm.org/docs/AttributeReference.html#convergent-clang-convergent-clang-convergent. We could make it better by inverting the logic because we will provide a way to specify where compiler doesn't have to be conservative with respect to optimizations that change CFG. This will allow more optimizations to happen on the calls that can't be analyzed statically. The details can be found in discussions on the review: https://reviews.llvm.org/D38113.<https://reviews.llvm.org/D38113> <https://reviews.llvm.org/D38113> - Fix CMake find provider for Clang Debian package. Address long-standing CMake issue with the Debian packaging for Clang (LLVM works), described here: https://bugs.debian.org/cgi-bin/bugreport.cgi?att=1;bug=862328.<https://bugs.debian.org/cgi-bin/bugreport.cgi?att=1;bug=862328> - Evaluate/gather some useful analysis data. We can collect some useful information that can help us to improve the compiler. This can be for example analysis of code coverage by the tests or compilation time hotspots. - Address some bugs that otherwise don't get bandwidth allocated to them. Cheers, Anastasia ________________________________ From: Anastasia Stulova Sent: 16 March 2018 15:15 To: clang-dev developer list; llvm-dev at lists.llvm.org Cc: nd Subject: Hacking at EuroLLVM 2018 Hello, We have booked a couple of slots during EuroLLVM this year that we would like to dedicate to real hacking!!! Therefore, we would like to offer to the attendees this year an opportunity to escape from the presentation sessions and dive into fun coding to learn something new or to solve some interesting problems. The current proposal is to have 2 x 45 mins on Monday afternoon and 2 x 45 mins sessions on Tuesday morning.We will have rooms with Internet and paper boards provided. We can pre-setup everything before the start to make sure we are more productive and perhaps even do some little homework offline before we meet. For the success of this event the key is to find suitable topics that can be either: - novel enough; - useful to someone (doesn't have to be everyone); - interesting; - challenging; - addressing long standing issue; or a combination of those. Ideally, we would like to see suggestions from you in which at least some part should be doable within half day with multiple developers on board. However, we also accept topics that require more time to be developed but for which some good concept can be developed within a couple of hours brainstorming session. Below are some ideas that could be addressed: - Improve support for outside of tree users. LLVM and Clang both have a lot of users that don't contribute to the main repository. They are often in the domain of embedded and heterogeneous targets. The code is typically kept confidential in the propriety toolchains but some is also available open source. Can we do something to make LLVM more friendly with respect to those? - Improve modularity of features. Clang and LLVM support wide number of languages and targets. This results in multiple problems i.e. large compiler binary size, interference during the development. Could we make it more modular? - Invert the logic of convergent attribute in LLVM. While adding the attribute to OpenCL functions we discussed that the semantic of convergent attribute is currently not optimal https://clang.llvm.org/docs/AttributeReference.html#convergent-clang-convergent-clang-convergent. We could make it better by inverting the logic because we will provide a way to specify where compiler doesn't have to be conservative with respect to optimizations that change CFG. This will allow more optimizations to happen on the calls that can't be analyzed statically<https://reviews.llvm.org/D38113>. The details can be found in discussions on the review: https://reviews.llvm.org/D38113.<https://reviews.llvm.org/D38113> <https://reviews.llvm.org/D38113> - Evaluate/gather some useful analysis data. We can collect some useful information that can help us to improve the compiler. This can be for example analysis of code coverage by the tests or compilation time hotspots. - Address some bugs that otherwise don't get bandwidth allocated to them. If you like any idea above please vote for it! Do you have any other interesting idea to hack? We would like to hear about it! Cheers, Anastasia -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180410/193d2a8e/attachment.html>