EuroLLVM "Round Table" topics

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

EuroLLVM "Round Table" topics

Tom Stellard via cfe-dev
Hi,
 
We are looking for new "Round Table" topics (i.e. mini-bof topics - formally known as hackers lab).  The round table sessions are a great way for us all to discuss face-to-face any burning topics. We have scheduled a table after each BoF sessions so that people can follow up on those conversation-topics.  We will also setup round tables during the event when there is interest (i.e. following an engaging presentation) - there will be whiteboards, and we will use the Sched.com app, to broadcast these spontaneous topics. 
 
Please suggest topics here, on this email thread, and we can add it to the schedule ahead of time.
 
Thanks
Phillip
 
------------------
Monday, April 16
3pm #pragma STDC FENV_ACCESS
4pm Debug Info 
 
Tuesday, April 17
10am Build system integration for interactive tools
10am LLVM for secure code
11:45am Clang Static Analyzer


_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: EuroLLVM "Round Table" topics

Tom Stellard via cfe-dev
I would like to discuss testing DAG combines.

It's an optimisation/canonicalisation path that all targets (that aren't using GlobalISel) are routed through and which occasionally contains bugs that are difficult to test for and difficult to work around.

Cheers

On Thu, Apr 12, 2018 at 10:18 AM, via cfe-dev <[hidden email]> wrote:
Send cfe-dev mailing list submissions to
        [hidden email]

To subscribe or unsubscribe via the World Wide Web, visit
        http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
or, via email, send a message with subject or body 'help' to
        [hidden email]

You can reach the person managing the list at
        [hidden email]

When replying, please edit your Subject line so it is more specific
than "Re: Contents of cfe-dev digest..."


Today's Topics:

   1. Re: JumboSupport: making unity builds easier in Clang
      (Daniel Bratell via cfe-dev)
   2. EuroLLVM "Round Table" topics (p23 power via cfe-dev)
   3. [RFC] How to communicate that -Wpedantic controls only
      certain cases of DiagGroups (Volodymyr Sapsai via cfe-dev)
   4. [libc++] use of allocator_traits (Axel Naumann via cfe-dev)


----------------------------------------------------------------------

Message: 1
Date: Wed, 11 Apr 2018 20:56:44 +0200
From: Daniel Bratell via cfe-dev <[hidden email]>
To: "Robinson, Paul" <[hidden email]>, Kim Gräsman
        <[hidden email]>
Cc: [hidden email], Daniel Cheng <[hidden email]>,
        Richard Smith <[hidden email]>, Clang Dev
        <[hidden email]>, [hidden email]
Subject: Re: [cfe-dev] JumboSupport: making unity builds easier in
        Clang
Message-ID: <op.zhblkuqurbppqq@cicero2.linkoping.osa>
Content-Type: text/plain; charset=utf-8; format=flowed; delsp=yes

It is different rates for maintaining and for initially adding support.

When first preparing the code for jumbo there are several groups of
changes necessary. Some of them are just that the code initially did
something wrong that is suddenly detected in jumbo builds, some of them is
that the same constant/function name is used in many files. kBufferSize,
kIconSize, kSecondsPerMinute, GetThingWithNullCheck(), those kind of
things.

In the initial cleanup I think names, the kind of problems clang support
as suggested would help with, is about 60-80%, and the experiment with
/net in Chromium supports that estimate.

After the initial cleanup, the new problems that appear seems to be of the
"duplicate symbol name" kind to a much higher degree, maybe 90%.

So if those rough estimates are correct, it would make it 4 times as easy
to implement something like jumbo, and 10 times as easy to maintain, and
it would mean that developers can use the short common names they have
become accustomed to.

It would also hide some code problems that jumbo right now expose, such as
copy/pasted code but if we can live with it today, we can probably survive
with that a while longer and leave it to other tools to find such problems.

/Daniel

(My notes from adding jumbo to a code part with 1000+ files, those with a
* would probably have been unnecessary if clang had had this support:
----
* 20.5 patches to rename something
* 11.5 patches to remove duplicate code
2 fixes to bad forward declarations
1 removal of "using namespace" (not allowed by the coding standard)
1 fix to ambiguity between ::prefs and ::metric::prefs
1 fix to clash with X11 headers
3 fixes to clashes with Windows headers
* 3 changes to inline trivial code/constants
1 case of bind.h finding Bind being called the wrong way thanks to access
to more type information
1 removal of dead code
1 patch to add include guards
)

On Wed, 11 Apr 2018 19:53:58 +0200, Kim Gräsman <[hidden email]>
wrote:

> See also: https://www.llvm.org/devmtg/2014-04/PDFs/Talks/Tenseconds.pdf
>
> I started experimenting with a unity build of an LLVM/Clang-sized
> proprietary project at my previous employer, and I found the basics
> easy to get going. The hard part was massaging the code base to avoid
> collisions, as indicated by the work by Mostyn & co.
>
> I left the job before I had a chance to fully evaluate it, but
> assuming I'd had something like `#pragma jumbo` to reduce the
> friction, it might have been easier to get more data for less effort.
>
> Mostyn/Daniel, do you have any gut feel/data on how much of the
> problem a #pragma would solve? I suppose there are still constructs
> that `#pragma jumbo` can't help with, that requires manual
> intervention?
>
> Also, Chromium is hardly a typical codebase, the little I've looked at
> it, it's *extremely* clean and consistent, so it might be interesting
> to try this on something else. Maybe LLVM itself would be an
> interesting candidate.
>
> - Kim
>
> On Wed, Apr 11, 2018 at 7:08 PM, via cfe-dev <[hidden email]>
> wrote:
>> If you want to share ASTs (an ephemeral structure) clang would need to
>> do
>> the distributing.  If you want to share IR of instantiated templates,
>> you
>> can do a shared database where clang is much less involved in managing
>> the
>> distribution.  Say the database key can be maybe a hash of the token
>> stream
>> of the template definition would work?  plus the template parameters.
>> Then
>> you can pull precompiled IR out of the database (if you want to do
>> optimizations) or make a reference to it (if you're doing LTO).
>>
>> --paulr
>>
>>
>>
>> From: cfe-dev [mailto:[hidden email]] On Behalf Of David
>> Blaikie via cfe-dev
>> Sent: Wednesday, April 11, 2018 11:09 AM
>> To: David Chisnall
>> Cc: Bruce Dawson; Daniel Cheng; [hidden email];
>> [hidden email]; Daniel Bratell; Jens Widell
>> Subject: Re: [cfe-dev] JumboSupport: making unity builds easier in Clang
>>
>>
>>
>> This would have issues with distributed builds, though, right? Unless
>> clang
>> then took on the burden of doing the distribution too, which might be a
>> bit
>> much.
>>
>> On Wed, Apr 11, 2018 at 12:43 AM David Chisnall via cfe-dev
>> <[hidden email]> wrote:
>>
>> On 10 Apr 2018, at 21:28, Daniel Bratell via cfe-dev
>> <[hidden email]> wrote:
>>>
>>> I've heard (hearsay, I admit) from profiling that it seems the single
>>> largest time consumer in clang is template instantiation, something I
>>> assume
>>> can't easily be prepared in advance.
>>>
>>> One example is chromium's chrome/browser/browser target which is 732
>>> files
>>> that normally need 6220 CPU seconds to compile, average 8,5 seconds per
>>> file. All combined together gives a single translation unit that takes
>>> 400
>>> seconds to compile, a mere 0.54 seconds on average per file. That
>>> indicates
>>> that about 8 seconds per compiled file is related to the processing of
>>> headers.
>>
>> It sounds as if there are two things here:
>>
>> 1. The time taken to parse the headers
>> 2. The time taken to repeatedly instantiate templates that the linker
>> will
>> then discard
>>
>> Assuming a command line where all of the relevant source files are
>> provided
>> to the compiler invocation:
>>
>> Solving the first one is relatively easy if the files have a common
>> prefix
>> (which can be determined by simple string comparison).  Find the common
>> prefix in the source files, build the clang AST, and then do a clone for
>> each compilation unit.  Hopefully, the clone is a lot cheaper than
>> re-parsing (and can ideally share source locations).
>>
>> The second is slightly more difficult, because it relies on sharing
>> parts of
>> the AST across notional compilation units.
>>
>> To make this work well with incremental builds, ideally you’d spit out
>> all
>> of the common template instantiations into a separate IR file, which
>> could
>> then be used with ThinLTO.
>>
>> Personally, I would prefer to have an interface where a build system can
>> invoke clang with all of the files that need building and the degree of
>> parallelism to use and let it share as much state as it wants across
>> builds.
>> In an ideal world, clang would record which templates have been
>> instantiated
>> in a prior build (or a previous build step in the current build) and
>> avoid
>> any IRGen for them, at the very least.
>>
>> Old C++ compilers, predating linker support for COMDATs, emitted
>> templates
>> lazily, simply emitting references to them, then parsing the linker
>> errors
>> and generating missing implementations until the linker errors went
>> away.
>> Modern C++ compilers generate many instantiations of the same templates
>> and
>> then discard most of them.  It would be nice to find an intermediate
>> point,
>> which worked well with ThinLTO, where templates could be emitted once
>> and be
>> available for inlining everywhere.
>>
>> David
>>
>> _______________________________________________
>> cfe-dev mailing list
>> [hidden email]
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>>
>>
>> _______________________________________________
>> cfe-dev mailing list
>> [hidden email]
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>>


--
/* Opera Software, Linköping, Sweden: CEST (UTC+2) */


------------------------------

Message: 2
Date: Wed, 11 Apr 2018 23:40:08 +0100
From: p23 power via cfe-dev <[hidden email]>
To: Clang Dev <[hidden email]>,  Xinliang David Li via
        llvm-dev <[hidden email]>, [hidden email],
        [hidden email]
Subject: [cfe-dev] EuroLLVM "Round Table" topics
Message-ID:
        <CAEVFM356XVOCx8xy_=[hidden email]>
Content-Type: text/plain; charset="utf-8"

Hi,

We are looking for new "Round Table" topics (i.e. mini-bof topics -
formally known as hackers lab).  The round table sessions are a great way
for us all to discuss face-to-face any burning topics. We have scheduled a
table after each BoF sessions so that people can follow up on those
conversation-topics.  We will also setup round tables during the event when
there is interest (i.e. following an engaging presentation) - there will be
whiteboards, and we will use the Sched.com app, to broadcast these
spontaneous topics.

Please suggest topics here, on this email thread, and we can add it to the
schedule ahead of time.

Thanks
Phillip

------------------
Monday, April 16
3pm #pragma STDC FENV_ACCESS
4pm Debug Info

Tuesday, April 17
10am Build system integration for interactive tools
10am LLVM for secure code
11:45am Clang Static Analyzer
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20180411/0265739a/attachment-0001.html>

------------------------------

Message: 3
Date: Wed, 11 Apr 2018 19:03:37 -0700
From: Volodymyr Sapsai via cfe-dev <[hidden email]>
To: cfe-dev <[hidden email]>
Subject: [cfe-dev] [RFC] How to communicate that -Wpedantic controls
        only certain cases of DiagGroups
Message-ID: <[hidden email]>
Content-Type: text/plain; charset="utf-8"

Hello all,

I’ll illustrate the problem with a situation encountered by our user. For some code compiled with -Wpedantic they encountered some -Wextra-semi warnings. So they’ve assumed that -Wpedantic controls -Wextra-semi but documentation <https://clang.llvm.org/docs/DiagnosticsReference.html#wpedantic> doesn’t say so. And it is correct because -Wpedantic enables all extension warnings but not disabled-by-default warnings. And for -Wextra-semi the DiagGroups structure is

ExtraSemi
  ext_extra_semi
  warn_extra_semi_after_mem_fn_def, DefaultIgnore
  CXX98CompatExtraSemi
    warn_cxx98_compat_top_level_semi, DefaultIgnore
  CXX11ExtraSemi
    ext_extra_semi_cxx11

So there are -Wextra-semi warnings that won’t be enabled by -Wpedantic.

I don’t think that Clang users should understand the intricacies of the DiagGroup structure to use it successfully. And provided example shows we don’t always achieve this goal. Does anybody have an idea how we can communicate that -Wpedantic can enable some warnings in certain cases but not in all cases? And should it be the case at all? Maybe it would be better if we don’t mix extension warnings and regular warnings in the same DiagGroup. I don’t suggest to update all the warnings to adhere to this requirement. But it can be useful to pay more attention to this in the future.

Thanks,
Volodymyr
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20180411/ea24a382/attachment-0001.html>

------------------------------

Message: 4
Date: Thu, 12 Apr 2018 11:20:56 +0200
From: Axel Naumann via cfe-dev <[hidden email]>
To: <[hidden email]>
Subject: [cfe-dev] [libc++] use of allocator_traits
Message-ID: <[hidden email]>
Content-Type: text/plain; charset="utf-8"

Hi,

I'm confused by libc++'s use of allocator_traits, for instance in
vector:898:
    __alloc_traits::__construct_backward(this->__alloc(),
this->__begin_, this->__end_, __v.__begin_);

The standard seems to not require the existence of a member called
__construct_backward. Seemingly standard-conforming, user provided
specializations of this trait (for a user provided allocator) thus fail
to compile.

Am I misinterpreting allocator_trait as a customization point?

Cheers, Axel.


------------------------------

Subject: Digest Footer

_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev


------------------------------

End of cfe-dev Digest, Vol 130, Issue 54
****************************************


_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev