[cfe-dev] Hacking at EuroLLVM 2018

[Anastasia Stulova via cfe-dev]

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/cfe-dev/attachments/20180320/6ce9ef62/attachment.html>