Have anybody experimented with release compilation flags when building dmd with ldc?

I'm currently calling make as

make -f posix.mak \
    DFLAGS="-noboundscheck" \
    ENABLE_RELEASE=1 \
    ENABLE_LTO=1 \
    HOST_CXX=g++ \
    HOST_DMD=ldmd2

And I measure about a 20-25% drop in runtime compared to the standard released version of dmd.

Is profile guided optimization (PGO) worth a try?

On Tuesday, 22 October 2019 at 14:02:28 UTC, Per Nordlöw wrote:
>     ENABLE_LTO=1 \

This has exactly 0 effect on DMD itself, from DMD's src/posix.mak:

ifdef ENABLE_LTO
CXXFLAGS  += -flto
endif

On Tuesday, 22 October 2019 at 18:55:03 UTC, kinke wrote:
> On Tuesday, 22 October 2019 at 14:02:28 UTC, Per Nordlöw wrote:
>>     ENABLE_LTO=1 \
>
> This has exactly 0 effect on DMD itself, from DMD's src/posix.mak:
>
> ifdef ENABLE_LTO
> CXXFLAGS  += -flto
> endif

So, I presume we could set

ifdef ENABLE_LTO
DFLAGS += -flto=full
endif

in the case when `HOST_DC` is either `ldmd2` or `ldc2` then, right?

This works for me.

On Wed, Oct 23, 2019 at 11:50 AM Per Nordlöw via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
>
> On Tuesday, 22 October 2019 at 18:55:03 UTC, kinke wrote:
> > On Tuesday, 22 October 2019 at 14:02:28 UTC, Per Nordlöw wrote:
> >>     ENABLE_LTO=1 \
> >
> > This has exactly 0 effect on DMD itself, from DMD's src/posix.mak:
> >
> > ifdef ENABLE_LTO
> > CXXFLAGS  += -flto
> > endif
>
> So, I presume we could set
>
> ifdef ENABLE_LTO
> DFLAGS += -flto=full
> endif
>
> in the case when `HOST_DC` is either `ldmd2` or `ldc2` then, right?
>
> This works for me.
https://bugs.archlinux.org/task/63569

On Wednesday, 23 October 2019 at 10:34:17 UTC, Daniel Kozak wrote:
>> This works for me.
> https://bugs.archlinux.org/task/63569

Shouldn't

 +ifeq ($(HOST_DMD_KIND), ldc)

be

 +ifeq ($(HOST_DMD_KIND), ldc2)

?

On Tuesday, 22 October 2019 at 14:02:28 UTC, Per Nordlöw wrote:
> Have anybody experimented with release compilation flags when building dmd with ldc?
> ...
> And I measure about a 20-25% drop in runtime compared to the standard released version of dmd.

Last time I checked it was about 40-50% (depends a bit on what you use to test, your machine etc.). So, yup the released binaries could be easily twice as fast. This is well known.
The problem is that no one except Martin has a full running setup of the release pipeline:

https://github.com/dlang/installer

Hence, this change hasn't happened.
IMHO, we should build them directly in the respective CIs like e.g. LDC does, because then anyone can easily modify and improve the setup.

> Is profile guided optimization (PGO) worth a try?

Yes.

On Wednesday, 23 October 2019 at 11:03:18 UTC, Per Nordlöw wrote:
> On Wednesday, 23 October 2019 at 10:34:17 UTC, Daniel Kozak wrote:
>>> This works for me.
>> https://bugs.archlinux.org/task/63569
>
> Shouldn't
>
>  +ifeq ($(HOST_DMD_KIND), ldc)
>
> be
>
>  +ifeq ($(HOST_DMD_KIND), ldc2)
>
> ?

ArchLinux ships LDC as ldc and ldc2.

https://github.com/ldc-developers/ldc/issues/2701

On Wed, Oct 23, 2019 at 1:05 PM Per Nordlöw via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
>
> On Wednesday, 23 October 2019 at 10:34:17 UTC, Daniel Kozak wrote:
> >> This works for me.
> > https://bugs.archlinux.org/task/63569
>
> Shouldn't
>
>   +ifeq ($(HOST_DMD_KIND), ldc)
>
> be
>
>   +ifeq ($(HOST_DMD_KIND), ldc2)
>
> ?
>

No,

if you look to posix.mak you will see this:

https://github.com/dlang/dmd/blob/v2.088.1/src/posix.mak#L167

ifneq (,$(findstring ldc,$(HOST_DMD_VERSION))$(findstring
LDC,$(HOST_DMD_VERSION)))
HOST_DMD_KIND=ldc
HOST_DMD_VERNUM=2
endif

On Wednesday, 23 October 2019 at 09:49:57 UTC, Per Nordlöw wrote:
> On Tuesday, 22 October 2019 at 18:55:03 UTC, kinke wrote:
>> On Tuesday, 22 October 2019 at 14:02:28 UTC, Per Nordlöw wrote:
>>>     ENABLE_LTO=1 \
>>
>> This has exactly 0 effect on DMD itself, from DMD's src/posix.mak:
>>
>> ifdef ENABLE_LTO
>> CXXFLAGS  += -flto
>> endif
>
> So, I presume we could set
>
> ifdef ENABLE_LTO
> DFLAGS += -flto=full
> endif
>
> in the case when `HOST_DC` is either `ldmd2` or `ldc2` then, right?
>
> This works for me.

My bad, I thought build.d was a replacement for the Makefile, instead the Makefile is based on it, so this should kick in: https://github.com/dlang/dmd/blob/ce7576f256d4efaff843f5e7d6ed39e8d7f32a4e/src/build.d#L781-L784

druntime is linked as machine code though, so an additional `-defaultlib=druntime-ldc-lto` (if available in the used LDC package, true for almost all official packages) would additionally enable LTO across DMD and druntime.

On Wed, Oct 23, 2019 at 1:25 PM kinke via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
>
>...
> My bad, I thought build.d was a replacement for the Makefile,
> instead the Makefile is based on it, so this should kick in:
> https://github.com/dlang/dmd/blob/ce7576f256d4efaff843f5e7d6ed39e8d7f32a4e/src/build.d#L781-L784
>
> druntime is linked as machine code though, so an additional `-defaultlib=druntime-ldc-lto` (if available in the used LDC package, true for almost all official packages) would additionally enable LTO across DMD and druntime.

Not exactly, build.d has been use only for some part of dmd, so this is reason why I have opened https://bugs.archlinux.org/task/63569. There has been mismatch (some code has been compiled witl LTO and some was not ). It is possible right now build.d is used for everything so it could work.