On Tuesday, 27 June 2017 at 17:55:02 UTC, Iain Buclaw wrote:

> Looks like it would be best to apply these PRs in the order listed:
>
> https://github.com/dlang/dmd/pull/5276 https://github.com/dlang/dmd/pull/5948 https://github.com/dlang/dmd/pull/6418

Thanks.  I actually wasn't aware, until yesterday, that GDC isn't using the DDMD frontend.  How do you usually handle such things?  Just use the transpiler between your ears?

Also, what's the plan for GDC w/ DDMD?

Mike

On 27 June 2017 at 23:27, Mike via D.gnu <d.gnu@puremagic.com> wrote:
> On Tuesday, 27 June 2017 at 17:55:02 UTC, Iain Buclaw wrote:
>
>> Looks like it would be best to apply these PRs in the order listed:
>>
>> https://github.com/dlang/dmd/pull/5276 https://github.com/dlang/dmd/pull/5948 https://github.com/dlang/dmd/pull/6418
>
>
> Thanks.  I actually wasn't aware, until yesterday, that GDC isn't using the DDMD frontend.  How do you usually handle such things?  Just use the transpiler between your ears?
>

Carefully backport as needed.  I have been given approval to create a dmd-cxx branch in dlang where I'll put the continued maintenance of the C++ implementation until a time when we're ready to switch.

> Also, what's the plan for GDC w/ DDMD?
>

Get it so that we can test the latest dmd/stable branch without changing any code (just swap out the dmd frontend).  When happy that everything works.  Keep in sync with dmd/stable branch, no more trailing behind releases.  Regressions in DMD are handled immediately, not after a new release has gone out.

Regards,
Iain.

On Tuesday, 27 June 2017 at 17:55:02 UTC, Iain Buclaw wrote:

> Looks like it would be best to apply these PRs in the order listed:
>
> https://github.com/dlang/dmd/pull/5276 https://github.com/dlang/dmd/pull/5948 https://github.com/dlang/dmd/pull/6418
>

Compiling https://github.com/JinShil/stm32f42_discovery_demo

GDC 7.1 Without https://github.com/D-Programming-GDC/GDC/pull/507
-----------------------------------------------------------------
time arm-none-eabi-gdc -c -O3 -nophoboslib -nostdinc -nodefaultlibs -nostdlib -fno-emit-moduleinfo -mthumb -mcpu=cortex-m4 -Isource/runtime -fno-bounds-check -fno-invariants -fno-in -fno-out -ffunction-sections -fdata-sections source/gcc/attribute.d source/board/package.d source/board/ILI9341.d source/board/lcd.d source/board/spi5.d source/board/statusLED.d source/board/random.d source/board/ltdc.d source/stm32f42/bus.d source/stm32f42/scb.d source/stm32f42/trace.d source/stm32f42/dma2d.d source/stm32f42/spi.d source/stm32f42/pwr.d source/stm32f42/rcc.d source/stm32f42/rng.d source/stm32f42/nvic.d source/stm32f42/mmio.d source/stm32f42/flash.d source/stm32f42/gpio.d source/stm32f42/ltdc.d source/main.d -o binary/firmware.o

real    1m14.780s
user    0m53.201s
sys     0m5.704s

time arm-none-eabi-ld binary/firmware.o -Tlinker/linker.ld --gc-sections -o binary/firmware

real    0m34.636s
user    0m33.120s
sys     0m1.201s



GDC 7.1 With https://github.com/D-Programming-GDC/GDC/pull/507
--------------------------------------------------------------
time arm-none-eabi-gdc -c -O3 -nophoboslib -nostdinc -nodefaultlibs -nostdlib -fno-emit-moduleinfo -mthumb -mcpu=cortex-m4 -Isource/runtime -fno-bounds-check -fno-invariants -fno-in -fno-out -ffunction-sections -fdata-sections source/gcc/attribute.d source/board/package.d source/board/ILI9341.d source/board/lcd.d source/board/spi5.d source/board/statusLED.d source/board/random.d source/board/ltdc.d source/stm32f42/bus.d source/stm32f42/scb.d source/stm32f42/trace.d source/stm32f42/dma2d.d source/stm32f42/spi.d source/stm32f42/pwr.d source/stm32f42/rcc.d source/stm32f42/rng.d source/stm32f42/nvic.d source/stm32f42/mmio.d source/stm32f42/flash.d source/stm32f42/gpio.d source/stm32f42/ltdc.d source/main.d -o binary/firmware.o

real    0m55.745s
user    0m50.962s
sys     0m2.338s

time arm-none-eabi-ld binary/firmware.o -Tlinker/linker.ld --gc-sections -o binary/firmware

real    0m33.768s
user    0m33.212s
sys     0m0.503s

PR507 eems to have made a mild improvement.

In an effort to draw a comparison, I modified the code as little as possible to get it to build with DMD, and this is the result:
--------------------------------------------------
time dmd -m32 -c -conf= -boundscheck=off -release -betterC -Isource/runtime source/gcc/attribute.d source/board/package.d source/board/ILI9341.d source/board/lcd.d source/board/spi5.d source/board/statusLED.d source/board/random.d source/board/ltdc.d source/stm32f42/bus.d source/stm32f42/scb.d source/stm32f42/trace.d source/stm32f42/dma2d.d source/stm32f42/spi.d source/stm32f42/pwr.d source/stm32f42/rcc.d source/stm32f42/rng.d source/stm32f42/nvic.d source/stm32f42/mmio.d source/stm32f42/flash.d source/stm32f42/gpio.d source/stm32f42/ltdc.d source/main.d -of=binary/firmware.o

real    0m3.086s
user    0m2.569s
sys     0m0.517s

Not sure if that's a valid comparison, but that's a huge difference.

I'd be glad to do some troubleshooting if you have any ideas.  But I may not get to it right away as I will be traveling for a few weeks.

Mike

On Wednesday, 28 June 2017 at 11:19:10 UTC, Mike wrote:
>
> I'd be glad to do some troubleshooting if you have any ideas.  But I may not get to it right away as I will be traveling for a few weeks.
>
> Mike

Are we sure this is a frontend problem?
Have you already tried -fsyntax-only to remove the backend computation?

Also which DMD version did you use for comparison? I'd try 2.068 (if your code compiles with that version) and 2.071.2. There may have been other changes in newer frontend versions improving build performance.

On Wednesday, 28 June 2017 at 12:15:17 UTC, Johannes Pfau wrote:

> Have you already tried -fsyntax-only to remove the backend computation?

time arm-none-eabi-gdc -c -O3 -fsyntax-only -nophoboslib -nostdinc -nodefaultlibs -nostdlib -fno-emit-moduleinfo -mthumb -mcpu=cortex-m4 -Isource/runtime -fno-bounds-check -fno-invariants -fno-in -fno-out -ffunction-sections -fdata-sections source/gcc/attribute.d source/board/package.d source/board/ILI9341.d source/board/lcd.d source/board/spi5.d source/board/statusLED.d source/board/random.d source/board/ltdc.d source/stm32f42/bus.d source/stm32f42/scb.d source/stm32f42/trace.d source/stm32f42/dma2d.d source/stm32f42/spi.d source/stm32f42/pwr.d source/stm32f42/rcc.d source/stm32f42/rng.d source/stm32f42/nvic.d source/stm32f42/mmio.d source/stm32f42/flash.d source/stm32f42/gpio.d source/stm32f42/ltdc.d source/main.d -o binary/firmware.o

real    0m1.858s
user    0m1.157s
sys     0m0.241s

Does that indicate a backend problem?  If you look at my previous post, linking was also quite high at 33s.

> Also which DMD version did you use for comparison? I'd try 2.068 (if your code compiles with that version) and 2.071.2. There may have been other changes in newer frontend versions improving build performance.

dmd --version
DMD64 D Compiler v2.074.0

Mike

On Wednesday, 28 June 2017 at 11:19:10 UTC, Mike wrote:

> I'd be glad to do some troubleshooting if you have any ideas.

I just checked in a branch that will compile with a desktop GDC compiler in case someone wants to give it a try.  I tested with 6.2.1 20160830 from the Arch Linux repository.

It won't produce a working binary, but it will go through the motions.

git clone https://github.com/JinShil/stm32f42_discovery_demo.git
cd stm32f42_discovery_demo/
git checkout desktop-gdc
rdmd build.d


Mike

Am Wed, 28 Jun 2017 12:27:17 +0000
schrieb Mike <none@none.com>:

> Does that indicate a backend problem?  If you look at my previous post, linking was also quite high at 33s.

Probably. AFAIR -fsyntax-only includes all frontend processing so the long runtime is likely due to the optimization phases, assembling and linking. However, let's wait for Iain for a more competent response ;-)

-- Johannes

Am Wed, 28 Jun 2017 12:56:40 +0000
schrieb Mike <none@none.com>:

> On Wednesday, 28 June 2017 at 11:19:10 UTC, Mike wrote:
> 
> > I'd be glad to do some troubleshooting if you have any ideas.
> 
> I just checked in a branch that will compile with a desktop GDC compiler in case someone wants to give it a try.  I tested with 6.2.1 20160830 from the Arch Linux repository.
> 
> It won't produce a working binary, but it will go through the motions.
> 
> git clone https://github.com/JinShil/stm32f42_discovery_demo.git
> cd stm32f42_discovery_demo/
> git checkout desktop-gdc
> rdmd build.d
> 
> 
> Mike

I guess if archlinux GDC is slow as well this is unlikely the main cause, but did you build your compiler in release mode (--enable-checking=release)?


-- Johannes

On Wednesday, 28 June 2017 at 13:48:54 UTC, Johannes Pfau wrote:

> I guess if archlinux GDC is slow as well this is unlikely the main cause, but did you build your compiler in release mode (--enable-checking=release)?

Thanks, I wasn't aware of that.  I just rebuilt and it brought the time down another 25%.

time arm-none-eabi-gdc -c -O3 -nophoboslib -nostdinc -nodefaultlibs -nostdlib -fno-emit-moduleinfo -mthumb -mcpu=cortex-m4 -Isource/runtime -fno-bounds-check -fno-invariants -fno-in -fno-out -ffunction-sections -fdata-sections source/gcc/attribute.d source/board/package.d source/board/ILI9341.d source/board/lcd.d source/board/spi5.d source/board/statusLED.d source/board/random.d source/board/ltdc.d source/stm32f42/bus.d source/stm32f42/scb.d source/stm32f42/trace.d source/stm32f42/dma2d.d source/stm32f42/spi.d source/stm32f42/pwr.d source/stm32f42/rcc.d source/stm32f42/rng.d source/stm32f42/nvic.d source/stm32f42/mmio.d source/stm32f42/flash.d source/stm32f42/gpio.d source/stm32f42/ltdc.d source/main.d -o binary/firmware.o

real    1m0.518s
user    0m54.594s
sys     0m2.558s

Mike

On 28 June 2017 at 13:19, Mike via D.gnu <d.gnu@puremagic.com> wrote:
>
> PR507 eems to have made a mild improvement.
>

OK, so will pull it in.  As what has already been said, if you aren't doing already, always use --enable-checking=release, any other value (apart from none) is for testing builds only.

You probably want to tone down on optimizations as well.  -O3 will be doing a lot of work, sometimes for little or no gain.  In most cases, -O2 -finline-functions is good enough, which can be abbreviated further as simply -Os.  [for full list of enabled/disabled passes: gdc -Q -Os --help=optimizers]

You can see a breakdown of what areas the compiler spends the most time in with -ftime-report

Regards,
Iain.