Testing GDC (GCC 7.1) on Runtime-less ARM Cortex-M

[Iain Buclaw via D.gnu]

On 18 July 2017 at 01:19, Iain Buclaw <ibuclaw at gdcproject.org> wrote:
> On 17 July 2017 at 22:26, Mike via D.gnu <d.gnu at puremagic.com> wrote:
>> On Wednesday, 28 June 2017 at 22:17:09 UTC, Iain Buclaw wrote:
>>
>>> A thought just occurred to me, you are compiling the entire program +
>>> object.d right?  Nothing else will link/be linked to the binary?
>>>
>>> If that is the case, you should definitely compile with -fwhole-program.
>>> I suspect that may cut down your compilation time by half or even more.
>>
>>
>> I'm back and have spend the last two days trying to get my project compiled
>> with -fwhole-program in an effort to reduce the compile times, but I haven't
>> had any success.
>>
>> Regardless of what I do, the compiler doesn't emit anything except main.
>>
>> arm-none-eabi-gdc -c -O2 -finline-functions -nophoboslib -nostdinc
>> -nodefaultlibs -nostdlib -fno-emit-moduleinfo -mthumb -mcpu=cortex-m4
>> -fwhole-program -Isource/entrypoint -fno-bounds-check -ffunction-sections
>> -fdata-sections source/gcc/attribute.d source/runtime/exception.d
>> source/runtime/invariant.d source/runtime/object.d source/runtime/dmain2.d
>> source/board/lcd.d source/board/ILI9341.d source/board/package.d
>> source/board/statusLED.d source/board/ltdc.d source/board/random.d
>> source/board/spi5.d source/stm32f42/nvic.d source/stm32f42/gpio.d
>> source/stm32f42/flash.d source/stm32f42/scb.d source/stm32f42/spi.d
>> source/stm32f42/pwr.d source/stm32f42/ltdc.d source/stm32f42/trace.d
>> source/stm32f42/rcc.d source/stm32f42/bus.d source/stm32f42/rng.d
>> source/stm32f42/dma2d.d source/stm32f42/mmio.d source/main.d -o
>> binary/firmware.o
>>
>> arm-none-eabi-nm binary/firmware.o
>>          U _Dmain
>>          U _d_run_main
>> 00000000 T main
>>
>> Are you sure this works with multiple modules passed to the compiler on one
>> line?
>>
>
> Humm, it looks like it can't sufficiently determine that both the
> _d_run_main declarations are for the same symbol.
>
> After making a tweak, it compiles a program that does a little bit more.


Infact, after inspecting the unoptimized result, I think I can safely
say this is the entire program, as it is intended to be built.

Now, what can we learn from this?  What can and should be done better?
 Could this be achieved without -fwhole-program?

So far, the compiler really does just force every symbol to be
emitted, at the cost of compilation time (no function can be removed
during optimization).  I think this is really just a workaround for
not setting properly the visibility for compiled symbols (there's a
lack of documentation in D about this), I think we could do better and
be more explicit in setting this up.  However the problem has almost
always been templates that get cut, but shouldn't have, and so end up
as being undefined at link-time.

There's probably a few bug reports to be raised.

Regards
Iain.