search for: r250000

Hi all, I recently did a run where I built clang executables on FreeBSD 12-CURRENT [1], from trunk r250000 (2015-10-11) all through r327700 (2018-03-16), with increments of 100 revisions. This is mainly meant as an archive, for easily doing bisections, but there are also some interesting statistics. From r250000 through r327700: * the total (stripped) executable size grew by approximately 43% * the si...

...have to share once back in the office. Thanks for sharing your data! -Greg On Sat, 17 Mar 2018 at 12:36, Dimitry Andric via cfe-dev < cfe-dev at lists.llvm.org> wrote: > Hi all, > > I recently did a run where I built clang executables on FreeBSD 12-CURRENT > [1], from trunk r250000 (2015-10-11) all through r327700 (2018-03-16), with > increments of 100 revisions. This is mainly meant as an archive, for > easily doing bisections, but there are also some interesting statistics. > > From r250000 through r327700: > * the total (stripped) executable size grew by ap...

...sharing your data! > > -Greg > > > > On Sat, 17 Mar 2018 at 12:36, Dimitry Andric via cfe-dev < > cfe-dev at lists.llvm.org> wrote: > >> Hi all, >> >> I recently did a run where I built clang executables on FreeBSD >> 12-CURRENT [1], from trunk r250000 (2015-10-11) all through r327700 >> (2018-03-16), with increments of 100 revisions. This is mainly meant as an >> archive, for easily doing bisections, but there are also some interesting >> statistics. >> >> From r250000 through r327700: >> * the total (strippe...

...data! > > -Greg > > > > On Sat, 17 Mar 2018 at 12:36, Dimitry Andric via cfe-dev <cfe-dev at lists.llvm.org <mailto:cfe-dev at lists.llvm.org>> wrote: > Hi all, > > I recently did a run where I built clang executables on FreeBSD 12-CURRENT [1], from trunk r250000 (2015-10-11) all through r327700 (2018-03-16), with increments of 100 revisions. This is mainly meant as an archive, for easily doing bisections, but there are also some interesting statistics. > > From r250000 through r327700: > * the total (stripped) executable size grew by approximate...

...> >> >> >> On Sat, 17 Mar 2018 at 12:36, Dimitry Andric via cfe-dev < >> cfe-dev at lists.llvm.org> wrote: >> >>> Hi all, >>> >>> I recently did a run where I built clang executables on FreeBSD >>> 12-CURRENT [1], from trunk r250000 (2015-10-11) all through r327700 >>> (2018-03-16), with increments of 100 revisions. This is mainly meant as an >>> archive, for easily doing bisections, but there are also some interesting >>> statistics. >>> >>> From r250000 through r327700: >>&...

...not a generic bitcode version scheme, because most bitcode format changes involve things like adding new operands or opcodes, which are easily identified without needing an explicit version number. The scenario I am most concerned about is this: - We as a vendor publish toolchain #12 based on SVN r250000. - During subsequent LLVM development, changes happen (!). For example, a new key letter 'g' in the Data Layout. This is not a bitcode ambiguity so MODULE_CODE_VERSION is unchanged. - We as a vendor publish toolchain #13 based on SVN r300000. - Some middleware provider publishes libInc...

...ing > > an explicit version number. > > That is what it is used for at the moment. It is is just a number, we > can increment it as often as we want. > > > The scenario I am most concerned about is this: > > > > - We as a vendor publish toolchain #12 based on SVN r250000. > > - During subsequent LLVM development, changes happen (!). > > For example, a new key letter 'g' in the Data Layout. This is > > not a bitcode ambiguity so MODULE_CODE_VERSION is unchanged. > > - We as a vendor publish toolchain #13 based on SVN r300000. &gt...

On Tue, Nov 4, 2014 at 9:10 PM, Bruce Hoult <bruce at hoult.org> wrote: > On Wed, Nov 5, 2014 at 2:30 PM, Sean Silva <chisophugis at gmail.com> wrote: > >> > Does Apple support library/middleware providers shipping bitcode instead >> >>> > of object code? >>> >>> No. >>> >> >> Are there ever any plans to do so?

...ing > > an explicit version number. > > That is what it is used for at the moment. It is is just a number, we > can increment it as often as we want. > > > The scenario I am most concerned about is this: > > > > - We as a vendor publish toolchain #12 based on SVN r250000. > > - During subsequent LLVM development, changes happen (!). > > For example, a new key letter 'g' in the Data Layout. This is > > not a bitcode ambiguity so MODULE_CODE_VERSION is unchanged. > > - We as a vendor publish toolchain #13 based on SVN r300000. &gt...