[llvm-dev] Code in headers

Anna Zaks via llvm-dev llvm-dev at lists.llvm.org
Sat Feb 13 15:00:43 PST 2016


> On Feb 11, 2016, at 12:43 AM, via llvm-dev <Alexander G. Riccio> wrote:
> 
> I don’t think that we can agree to abstract code guidelines without knowing what it means in practice for the codebase. If you’re interested in this, please include a diff that shows the impact to the headers, and we should also measure what happens to the performance of the generated compiler.
> 
> I think he's referring to the coding standards there... but I'll assume that you're responding to me. 
> 
> we should also measure what happens to the performance of the generated compiler.
> 
> I agree, but how do we do that?
> 

I suspect that in order to make the policy for all of clang and llvm, you need to experiment with more than the 4 headers from the patch. You would need to measure the performance of the generated compiler on large projects. I’d include LLVM and clang in the set, but maybe more is needed. You should measure the performance of the generated static analyzer on the projects from the static analyzer extended tests suite.

> Many LLVM/Clang headers have lots of complex code in headers - I'm specifically looking at the Static Analyzer projects
Can you point to the analyzer headers that have "lots of complex code"? We try to move all of the complex implementations into the cpp files. Checkers do not have headers at all.

> (seemingly slowest compile times, biggest hinderance to my productivity)
Building static analyzer is not slower than building clang. llvm/clang is known for slow compile times. You an search the archive for discussions on how those could be lowered.

> See: http://reviews.llvm.org/D17130 <http://reviews.llvm.org/D17130> 

Most of the changes in the patch move trivial constructor implementations “{}” out of the headers. There are only a couple that span more than one line of code. These implementations have not changed for months/years so it’s not likely you’ll suffer from rebuilding everything while modifying them.

> 
> Sincerely,
> Alexander Riccio
> --
> "Change the world or go home."
> about.me/ariccio <http://about.me/ariccio>
> 
>  <http://about.me/ariccio>
> If left to my own devices, I will build more.
>> 
> On Wed, Feb 10, 2016 at 11:05 PM, Chris Lattner <clattner at apple.com <mailto:clattner at apple.com>> wrote:
> 
>> On Feb 10, 2016, at 7:34 PM, George Burgess IV via llvm-dev <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote:
>> 
>> > Someone should stick it in the coding standards?
>> 
>> I'm happy to give this a shot.
> 
> My 2c: I don’t think that we can agree to abstract code guidelines without knowing what it means in practice for the codebase.  If you’re interested in this, please include a diff that shows the impact to the headers, and we should also measure what happens to the performance of the generated compiler.
> 
> -Chris
> 
> 
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev <http://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/20160213/4771c899/attachment.html>


More information about the llvm-dev mailing list