[cfe-dev] Best practices

[Devchandra L Meetei]

Yup, I agree with your last point as this is open source project.
Unfortunately, I use for clang for our open source project, so unable to
afford someone, who can do it for us.
So unless someone volunteers to do it. People will be inclined to use clang
for development build but at the time of release, we will resort to gcc.
Regards
--Dev

On Thu, Sep 27, 2012 at 11:28 PM, Matthieu Monrocq <
matthieu.monrocq at gmail.com> wrote:

> I seriously doubt that synthetic benchmarks are very much valued. They are
> nice to expose pathological behaviors, but not much beyond that.
>
> It just seems that this is of lower priority than other stuff (C++11
> support !!) and that you just happen to care more about that the average
> user.
>
> Still, this is an open source project, so if nobody deals with it and you
> happen to really need it, maybe you could delve into it yourself or try to
> find someone to do it for you ? (maybe even a contractor) The community is
> generally welcoming to developers, so don't be shy :)
>
> -- Matthieu
>
>
> On Thu, Sep 27, 2012 at 7:15 PM, Devchandra L Meetei <dlmeetei at gmail.com>wrote:
>
>> If this is the case, Too bad.
>>
>> On Thu, Sep 27, 2012 at 10:18 PM, Domagoj Saric <
>> domagoj.saric at littleendian.com> wrote:
>>
>>> On 23.9.2012. 16:21, Devchandra L Meetei wrote:
>>> > Hi clangers
>>> > is there any best practices which can be used to to reduce disk
>>> footprints of
>>> > executable and lib generated by clangs,
>>> > Usually binaries generated by clang is larger than those of gcc.
>>>
>>>
>>> I can confirm that Clang's record WRT codegen size is quite far from
>>> good. The main problems I've identified are:
>>> - excessive inlining (even with -Os)
>>> - template bloat
>>> - no support for fno-inline, -fno-inline-functions or -finline-limit
>>>
>>> Here are some related tickets by me (you can find some tips how to
>>> "minimize damage"):
>>> http://llvm.org/bugs/show_bug.**cgi?id=11625<http://llvm.org/bugs/show_bug.cgi?id=11625>
>>> http://llvm.org/bugs/show_bug.**cgi?id=11633<http://llvm.org/bugs/show_bug.cgi?id=11633>
>>>
>>> By others:
>>> http://llvm.org/bugs/show_bug.**cgi?id=4435<http://llvm.org/bugs/show_bug.cgi?id=4435>
>>> http://llvm.org/bugs/show_bug.**cgi?id=4573<http://llvm.org/bugs/show_bug.cgi?id=4573>
>>> http://llvm.org/bugs/show_bug.**cgi?id=5124<http://llvm.org/bugs/show_bug.cgi?id=5124>
>>> http://llvm.org/bugs/show_bug.**cgi?id=11083<http://llvm.org/bugs/show_bug.cgi?id=11083>
>>>
>>> These don't help either:
>>> http://llvm.org/bugs/show_bug.**cgi?id=11544<http://llvm.org/bugs/show_bug.cgi?id=11544>
>>> http://llvm.org/bugs/show_bug.**cgi?id=11624<http://llvm.org/bugs/show_bug.cgi?id=11624>
>>>
>>>
>>> ...from the date of the tickets and lack of response one can only deduce
>>> that this is of no or very low priority to Clang developers (or in "bitch
>>> mode": they only care about synthetic benchmarks and not about real world
>>> behaviour)... :/
>>>
>>>
>>> --
>>> "What Huxley teaches is that in the age of advanced technology, spiritual
>>> devastation is more likely to come from an enemy with a smiling face than
>>> from one whose countenance exudes suspicion and hate."
>>> Neil Postman
>>> ______________________________**_________________
>>> cfe-dev mailing list
>>> cfe-dev at cs.uiuc.edu
>>> http://lists.cs.uiuc.edu/**mailman/listinfo/cfe-dev<http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev>
>>>
>>
>>
>> _______________________________________________
>> cfe-dev mailing list
>> cfe-dev at cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20120928/9894f455/attachment.html>