<div dir="ltr">I would like to discuss testing DAG combines.<div><br><div>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.<br><div class="gmail_extra"><br></div><div class="gmail_extra">Cheers</div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Apr 12, 2018 at 10:18 AM, via cfe-dev <span dir="ltr"><<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Send cfe-dev mailing list submissions to<br>
<a href="mailto:cfe-dev@lists.llvm.org">cfe-dev@lists.llvm.org</a><br>
<br>
To subscribe or unsubscribe via the World Wide Web, visit<br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/<wbr>mailman/listinfo/cfe-dev</a><br>
or, via email, send a message with subject or body 'help' to<br>
<a href="mailto:cfe-dev-request@lists.llvm.org">cfe-dev-request@lists.llvm.org</a><br>
<br>
You can reach the person managing the list at<br>
<a href="mailto:cfe-dev-owner@lists.llvm.org">cfe-dev-owner@lists.llvm.org</a><br>
<br>
When replying, please edit your Subject line so it is more specific<br>
than "Re: Contents of cfe-dev digest..."<br>
<br>
<br>
Today's Topics:<br>
<br>
1. Re: JumboSupport: making unity builds easier in Clang<br>
(Daniel Bratell via cfe-dev)<br>
2. EuroLLVM "Round Table" topics (p23 power via cfe-dev)<br>
3. [RFC] How to communicate that -Wpedantic controls only<br>
certain cases of DiagGroups (Volodymyr Sapsai via cfe-dev)<br>
4. [libc++] use of allocator_traits (Axel Naumann via cfe-dev)<br>
<br>
<br>
------------------------------<wbr>------------------------------<wbr>----------<br>
<br>
Message: 1<br>
Date: Wed, 11 Apr 2018 20:56:44 +0200<br>
From: Daniel Bratell via cfe-dev <<a href="mailto:cfe-dev@lists.llvm.org">cfe-dev@lists.llvm.org</a>><br>
To: "Robinson, Paul" <<a href="mailto:paul.robinson@sony.com">paul.robinson@sony.com</a>>, Kim Gräsman<br>
<<a href="mailto:kim.grasman@gmail.com">kim.grasman@gmail.com</a>><br>
Cc: <a href="mailto:brucedawson@chromium.org">brucedawson@chromium.org</a>, Daniel Cheng <<a href="mailto:dcheng@chromium.org">dcheng@chromium.org</a>>,<br>
Richard Smith <<a href="mailto:richard@metafoo.co.uk">richard@metafoo.co.uk</a>>, Clang Dev<br>
<<a href="mailto:cfe-dev@lists.llvm.org">cfe-dev@lists.llvm.org</a>>, <a href="mailto:jl@opera.com">jl@opera.com</a><br>
Subject: Re: [cfe-dev] JumboSupport: making unity builds easier in<br>
Clang<br>
Message-ID: <op.zhblkuqurbppqq@cicero2.<wbr>linkoping.osa><br>
Content-Type: text/plain; charset=utf-8; format=flowed; delsp=yes<br>
<br>
It is different rates for maintaining and for initially adding support.<br>
<br>
When first preparing the code for jumbo there are several groups of<br>
changes necessary. Some of them are just that the code initially did<br>
something wrong that is suddenly detected in jumbo builds, some of them is<br>
that the same constant/function name is used in many files. kBufferSize,<br>
kIconSize, kSecondsPerMinute, GetThingWithNullCheck(), those kind of<br>
things.<br>
<br>
In the initial cleanup I think names, the kind of problems clang support<br>
as suggested would help with, is about 60-80%, and the experiment with<br>
/net in Chromium supports that estimate.<br>
<br>
After the initial cleanup, the new problems that appear seems to be of the<br>
"duplicate symbol name" kind to a much higher degree, maybe 90%.<br>
<br>
So if those rough estimates are correct, it would make it 4 times as easy<br>
to implement something like jumbo, and 10 times as easy to maintain, and<br>
it would mean that developers can use the short common names they have<br>
become accustomed to.<br>
<br>
It would also hide some code problems that jumbo right now expose, such as<br>
copy/pasted code but if we can live with it today, we can probably survive<br>
with that a while longer and leave it to other tools to find such problems.<br>
<br>
/Daniel<br>
<br>
(My notes from adding jumbo to a code part with 1000+ files, those with a<br>
* would probably have been unnecessary if clang had had this support:<br>
----<br>
* 20.5 patches to rename something<br>
* 11.5 patches to remove duplicate code<br>
2 fixes to bad forward declarations<br>
1 removal of "using namespace" (not allowed by the coding standard)<br>
1 fix to ambiguity between ::prefs and ::metric::prefs<br>
1 fix to clash with X11 headers<br>
3 fixes to clashes with Windows headers<br>
* 3 changes to inline trivial code/constants<br>
1 case of bind.h finding Bind being called the wrong way thanks to access<br>
to more type information<br>
1 removal of dead code<br>
1 patch to add include guards<br>
)<br>
<br>
On Wed, 11 Apr 2018 19:53:58 +0200, Kim Gräsman <<a href="mailto:kim.grasman@gmail.com">kim.grasman@gmail.com</a>><br>
wrote:<br>
<br>
> See also: <a href="https://www.llvm.org/devmtg/2014-04/PDFs/Talks/Tenseconds.pdf" rel="noreferrer" target="_blank">https://www.llvm.org/devmtg/<wbr>2014-04/PDFs/Talks/Tenseconds.<wbr>pdf</a><br>
><br>
> I started experimenting with a unity build of an LLVM/Clang-sized<br>
> proprietary project at my previous employer, and I found the basics<br>
> easy to get going. The hard part was massaging the code base to avoid<br>
> collisions, as indicated by the work by Mostyn & co.<br>
><br>
> I left the job before I had a chance to fully evaluate it, but<br>
> assuming I'd had something like `#pragma jumbo` to reduce the<br>
> friction, it might have been easier to get more data for less effort.<br>
><br>
> Mostyn/Daniel, do you have any gut feel/data on how much of the<br>
> problem a #pragma would solve? I suppose there are still constructs<br>
> that `#pragma jumbo` can't help with, that requires manual<br>
> intervention?<br>
><br>
> Also, Chromium is hardly a typical codebase, the little I've looked at<br>
> it, it's *extremely* clean and consistent, so it might be interesting<br>
> to try this on something else. Maybe LLVM itself would be an<br>
> interesting candidate.<br>
><br>
> - Kim<br>
><br>
> On Wed, Apr 11, 2018 at 7:08 PM, via cfe-dev <<a href="mailto:cfe-dev@lists.llvm.org">cfe-dev@lists.llvm.org</a>><br>
> wrote:<br>
>> If you want to share ASTs (an ephemeral structure) clang would need to<br>
>> do<br>
>> the distributing. If you want to share IR of instantiated templates,<br>
>> you<br>
>> can do a shared database where clang is much less involved in managing<br>
>> the<br>
>> distribution. Say the database key can be maybe a hash of the token<br>
>> stream<br>
>> of the template definition would work? plus the template parameters.<br>
>> Then<br>
>> you can pull precompiled IR out of the database (if you want to do<br>
>> optimizations) or make a reference to it (if you're doing LTO).<br>
>><br>
>> --paulr<br>
>><br>
>><br>
>><br>
>> From: cfe-dev [mailto:<a href="mailto:cfe-dev-bounces@lists.llvm.org">cfe-dev-bounces@lists.<wbr>llvm.org</a>] On Behalf Of David<br>
>> Blaikie via cfe-dev<br>
>> Sent: Wednesday, April 11, 2018 11:09 AM<br>
>> To: David Chisnall<br>
>> Cc: Bruce Dawson; Daniel Cheng; <a href="mailto:richard@metafoo.co.uk">richard@metafoo.co.uk</a>;<br>
>> <a href="mailto:cfe-dev@lists.llvm.org">cfe-dev@lists.llvm.org</a>; Daniel Bratell; Jens Widell<br>
>> Subject: Re: [cfe-dev] JumboSupport: making unity builds easier in Clang<br>
>><br>
>><br>
>><br>
>> This would have issues with distributed builds, though, right? Unless<br>
>> clang<br>
>> then took on the burden of doing the distribution too, which might be a<br>
>> bit<br>
>> much.<br>
>><br>
>> On Wed, Apr 11, 2018 at 12:43 AM David Chisnall via cfe-dev<br>
>> <<a href="mailto:cfe-dev@lists.llvm.org">cfe-dev@lists.llvm.org</a>> wrote:<br>
>><br>
>> On 10 Apr 2018, at 21:28, Daniel Bratell via cfe-dev<br>
>> <<a href="mailto:cfe-dev@lists.llvm.org">cfe-dev@lists.llvm.org</a>> wrote:<br>
>>><br>
>>> I've heard (hearsay, I admit) from profiling that it seems the single<br>
>>> largest time consumer in clang is template instantiation, something I<br>
>>> assume<br>
>>> can't easily be prepared in advance.<br>
>>><br>
>>> One example is chromium's chrome/browser/browser target which is 732<br>
>>> files<br>
>>> that normally need 6220 CPU seconds to compile, average 8,5 seconds per<br>
>>> file. All combined together gives a single translation unit that takes<br>
>>> 400<br>
>>> seconds to compile, a mere 0.54 seconds on average per file. That<br>
>>> indicates<br>
>>> that about 8 seconds per compiled file is related to the processing of<br>
>>> headers.<br>
>><br>
>> It sounds as if there are two things here:<br>
>><br>
>> 1. The time taken to parse the headers<br>
>> 2. The time taken to repeatedly instantiate templates that the linker<br>
>> will<br>
>> then discard<br>
>><br>
>> Assuming a command line where all of the relevant source files are<br>
>> provided<br>
>> to the compiler invocation:<br>
>><br>
>> Solving the first one is relatively easy if the files have a common<br>
>> prefix<br>
>> (which can be determined by simple string comparison). Find the common<br>
>> prefix in the source files, build the clang AST, and then do a clone for<br>
>> each compilation unit. Hopefully, the clone is a lot cheaper than<br>
>> re-parsing (and can ideally share source locations).<br>
>><br>
>> The second is slightly more difficult, because it relies on sharing<br>
>> parts of<br>
>> the AST across notional compilation units.<br>
>><br>
>> To make this work well with incremental builds, ideally you’d spit out<br>
>> all<br>
>> of the common template instantiations into a separate IR file, which<br>
>> could<br>
>> then be used with ThinLTO.<br>
>><br>
>> Personally, I would prefer to have an interface where a build system can<br>
>> invoke clang with all of the files that need building and the degree of<br>
>> parallelism to use and let it share as much state as it wants across<br>
>> builds.<br>
>> In an ideal world, clang would record which templates have been<br>
>> instantiated<br>
>> in a prior build (or a previous build step in the current build) and<br>
>> avoid<br>
>> any IRGen for them, at the very least.<br>
>><br>
>> Old C++ compilers, predating linker support for COMDATs, emitted<br>
>> templates<br>
>> lazily, simply emitting references to them, then parsing the linker<br>
>> errors<br>
>> and generating missing implementations until the linker errors went<br>
>> away.<br>
>> Modern C++ compilers generate many instantiations of the same templates<br>
>> and<br>
>> then discard most of them. It would be nice to find an intermediate<br>
>> point,<br>
>> which worked well with ThinLTO, where templates could be emitted once<br>
>> and be<br>
>> available for inlining everywhere.<br>
>><br>
>> David<br>
>><br>
>> ______________________________<wbr>_________________<br>
>> cfe-dev mailing list<br>
>> <a href="mailto:cfe-dev@lists.llvm.org">cfe-dev@lists.llvm.org</a><br>
>> <a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/<wbr>mailman/listinfo/cfe-dev</a><br>
>><br>
>><br>
>> ______________________________<wbr>_________________<br>
>> cfe-dev mailing list<br>
>> <a href="mailto:cfe-dev@lists.llvm.org">cfe-dev@lists.llvm.org</a><br>
>> <a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/<wbr>mailman/listinfo/cfe-dev</a><br>
>><br>
<br>
<br>
--<br>
/* Opera Software, Linköping, Sweden: CEST (UTC+2) */<br>
<br>
<br>
------------------------------<br>
<br>
Message: 2<br>
Date: Wed, 11 Apr 2018 23:40:08 +0100<br>
From: p23 power via cfe-dev <<a href="mailto:cfe-dev@lists.llvm.org">cfe-dev@lists.llvm.org</a>><br>
To: Clang Dev <<a href="mailto:cfe-dev@lists.llvm.org">cfe-dev@lists.llvm.org</a>>, Xinliang David Li via<br>
llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>>, <a href="mailto:llvm-devmeeting@lists.llvm.org">llvm-devmeeting@lists.llvm.org</a><wbr>,<br>
<a href="mailto:lldb-dev@lists.llvm.org">lldb-dev@lists.llvm.org</a><br>
Subject: [cfe-dev] EuroLLVM "Round Table" topics<br>
Message-ID:<br>
<CAEVFM356XVOCx8xy_=<a href="mailto:HXwr1Nq-Gcskf4zUtVJWi-JuzkxVw4nA@mail.gmail.com">HXwr1Nq-<wbr>Gcskf4zUtVJWi-JuzkxVw4nA@mail.<wbr>gmail.com</a>><br>
Content-Type: text/plain; charset="utf-8"<br>
<br>
Hi,<br>
<br>
We are looking for new "Round Table" topics (i.e. mini-bof topics -<br>
formally known as hackers lab). The round table sessions are a great way<br>
for us all to discuss face-to-face any burning topics. We have scheduled a<br>
table after each BoF sessions so that people can follow up on those<br>
conversation-topics. We will also setup round tables during the event when<br>
there is interest (i.e. following an engaging presentation) - there will be<br>
whiteboards, and we will use the Sched.com app, to broadcast these<br>
spontaneous topics.<br>
<br>
Please suggest topics here, on this email thread, and we can add it to the<br>
schedule ahead of time.<br>
<br>
Thanks<br>
Phillip<br>
<br>
------------------<br>
Monday, April 16<br>
3pm #pragma STDC FENV_ACCESS<br>
4pm Debug Info<br>
<br>
Tuesday, April 17<br>
10am Build system integration for interactive tools<br>
10am LLVM for secure code<br>
11:45am Clang Static Analyzer<br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="http://lists.llvm.org/pipermail/cfe-dev/attachments/20180411/0265739a/attachment-0001.html" rel="noreferrer" target="_blank">http://lists.llvm.org/<wbr>pipermail/cfe-dev/attachments/<wbr>20180411/0265739a/attachment-<wbr>0001.html</a>><br>
<br>
------------------------------<br>
<br>
Message: 3<br>
Date: Wed, 11 Apr 2018 19:03:37 -0700<br>
From: Volodymyr Sapsai via cfe-dev <<a href="mailto:cfe-dev@lists.llvm.org">cfe-dev@lists.llvm.org</a>><br>
To: cfe-dev <<a href="mailto:cfe-dev@lists.llvm.org">cfe-dev@lists.llvm.org</a>><br>
Subject: [cfe-dev] [RFC] How to communicate that -Wpedantic controls<br>
only certain cases of DiagGroups<br>
Message-ID: <<a href="mailto:ED2215FB-2440-43B0-A8B4-247871E00460@apple.com">ED2215FB-2440-43B0-A8B4-<wbr>247871E00460@apple.com</a>><br>
Content-Type: text/plain; charset="utf-8"<br>
<br>
Hello all,<br>
<br>
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 <<a href="https://clang.llvm.org/docs/DiagnosticsReference.html#wpedantic" rel="noreferrer" target="_blank">https://clang.llvm.org/docs/<wbr>DiagnosticsReference.html#<wbr>wpedantic</a>> 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<br>
<br>
ExtraSemi<br>
ext_extra_semi<br>
warn_extra_semi_after_mem_fn_<wbr>def, DefaultIgnore<br>
CXX98CompatExtraSemi<br>
warn_cxx98_compat_top_level_<wbr>semi, DefaultIgnore<br>
CXX11ExtraSemi<br>
ext_extra_semi_cxx11<br>
<br>
So there are -Wextra-semi warnings that won’t be enabled by -Wpedantic.<br>
<br>
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.<br>
<br>
Thanks,<br>
Volodymyr<br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="http://lists.llvm.org/pipermail/cfe-dev/attachments/20180411/ea24a382/attachment-0001.html" rel="noreferrer" target="_blank">http://lists.llvm.org/<wbr>pipermail/cfe-dev/attachments/<wbr>20180411/ea24a382/attachment-<wbr>0001.html</a>><br>
<br>
------------------------------<br>
<br>
Message: 4<br>
Date: Thu, 12 Apr 2018 11:20:56 +0200<br>
From: Axel Naumann via cfe-dev <<a href="mailto:cfe-dev@lists.llvm.org">cfe-dev@lists.llvm.org</a>><br>
To: <<a href="mailto:cfe-dev@lists.llvm.org">cfe-dev@lists.llvm.org</a>><br>
Subject: [cfe-dev] [libc++] use of allocator_traits<br>
Message-ID: <<a href="mailto:a2d6df48-3ac3-61b4-ff32-3feb4b73cfaa@cern.ch">a2d6df48-3ac3-61b4-ff32-<wbr>3feb4b73cfaa@cern.ch</a>><br>
Content-Type: text/plain; charset="utf-8"<br>
<br>
Hi,<br>
<br>
I'm confused by libc++'s use of allocator_traits, for instance in<br>
vector:898:<br>
__alloc_traits::__construct_<wbr>backward(this->__alloc(),<br>
this->__begin_, this->__end_, __v.__begin_);<br>
<br>
The standard seems to not require the existence of a member called<br>
__construct_backward. Seemingly standard-conforming, user provided<br>
specializations of this trait (for a user provided allocator) thus fail<br>
to compile.<br>
<br>
Am I misinterpreting allocator_trait as a customization point?<br>
<br>
Cheers, Axel.<br>
<br>
<br>
------------------------------<br>
<br>
Subject: Digest Footer<br>
<br>
______________________________<wbr>_________________<br>
cfe-dev mailing list<br>
<a href="mailto:cfe-dev@lists.llvm.org">cfe-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/<wbr>mailman/listinfo/cfe-dev</a><br>
<br>
<br>
------------------------------<br>
<br>
End of cfe-dev Digest, Vol 130, Issue 54<br>
******************************<wbr>**********<br>
</blockquote></div><br></div></div></div></div>