On Monday, 17 July 2017 at 23:57:02 UTC, Iain Buclaw wrote:
Infact, after inspecting the unoptimized result, I think I can
safely say this is the entire program, as it is intended to be
built.
If I compile without optimizations, I am able to get a complete
binary also, even without the cha
On 18 July 2017 at 01:19, Iain Buclaw wrote:
> On 17 July 2017 at 22:26, Mike via D.gnu 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 th
On 17 July 2017 at 22:26, Mike via D.gnu 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 defi
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 c
On 29 June 2017 at 00:50, Mike via D.gnu wrote:
> On Wednesday, 28 June 2017 at 22:17:09 UTC, Iain Buclaw wrote:
>> 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.
>
>
> If I only import __entrypoin
On Wednesday, 28 June 2017 at 22:17:09 UTC, Iain Buclaw wrote:
Phase opt and generate is the topl-evel timer for the entire
"backend" compilation phase. I was expecting to see more of a
breakdown of individual passes.
Sorry, it didn't look broken down to me. Here's the full report.
arm-non
On 28 June 2017 at 23:15, Mike via D.gnu wrote:
> -
> The vast majority of time is spent in "phase opt and generate". A few
> observations:
>
> * Elapsed time isn't much different between -O3 and -O2 -finline-functions
> * -O
On Wednesday, 28 June 2017 at 16:52:26 UTC, Iain Buclaw wrote:
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. [fo
On 28 June 2017 at 13:19, Mike via D.gnu 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
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
Am Wed, 28 Jun 2017 12:56:40 +
schrieb 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
Am Wed, 28 Jun 2017 12:27:17 +
schrieb Mike :
> 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, assemblin
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.
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 -
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
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/stm32
On 27 June 2017 at 23:27, Mike via D.gnu 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
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 yest
On 26 June 2017 at 04:23, Mike via D.gnu wrote:
> On Sunday, 25 June 2017 at 10:18:04 UTC, Mike wrote:
>
>> Compile Speed
>> =
>> It takes about 1 minute 30 seconds to build and link the STM32 demo
>> resulting in a 6kB binary. That's pretty bad, but I suspect that's a DMD
>> CTFE pro
On Sunday, 25 June 2017 at 13:40:56 UTC, Iain Buclaw wrote:
I'll make a formal PR when I have some time later.
Iain.
For those who may encounter this post at a later date, the PR is
here: https://github.com/D-Programming-GDC/GDC/pull/505 and it
seems to solve the problem. Yeah!
On 26 June 2017 at 04:23, Mike via D.gnu wrote:
> On Sunday, 25 June 2017 at 10:18:04 UTC, Mike wrote:
>
>> Compile Speed
>> =
>> It takes about 1 minute 30 seconds to build and link the STM32 demo
>> resulting in a 6kB binary. That's pretty bad, but I suspect that's a DMD
>> CTFE pro
On Sunday, 25 June 2017 at 10:18:04 UTC, Mike wrote:
Compile Speed
=
It takes about 1 minute 30 seconds to build and link the STM32
demo resulting in a 6kB binary. That's pretty bad, but I
suspect that's a DMD CTFE problem.
I'm been informed that this PR
(https://github.com/dla
Am Sun, 25 Jun 2017 10:53:35 +
schrieb Mike :
>
> I'm not really interested in that because its too blunt of an
> instrument. I'd like to use TypeInfo, but only if I'm doing
> dynamic casts or other things that require such runtime
> information. Also, I'd only want the TypeInfo for the
On 25 June 2017 at 13:30, Mike via D.gnu wrote:
> On Sunday, 25 June 2017 at 10:53:35 UTC, Mike wrote:
>
>> I'm not really interested in that because its too blunt of an instrument.
>> I'd like to use TypeInfo, but only if I'm doing dynamic casts or other
>> things that require such runtime inform
On Sunday, 25 June 2017 at 10:53:35 UTC, Mike wrote:
I'm not really interested in that because its too blunt of an
instrument. I'd like to use TypeInfo, but only if I'm doing
dynamic casts or other things that require such runtime
information. Also, I'd only want the TypeInfo for the types
On Sunday, 25 June 2017 at 10:44:26 UTC, Iain Buclaw wrote:
Out of curiosity, is that the original built binary, or post
trimming
(strip / --gc-sections)?
I'm compiling with -ffunction-sections and -fdata-sections, and
linking with --gc-sections.
There might be a size optimization possibili
On 25 June 2017 at 12:18, Mike via D.gnu wrote:
> This is just an experience report for those who might be interested.
>
> Given this pull request (https://github.com/D-Programming-GDC/GDC/pull/456)
> I thought I'd try testing a more recent GDC with my STM32 demo
> (https://github.com/JinShil/stm3
This is just an experience report for those who might be
interested.
Given this pull request
(https://github.com/D-Programming-GDC/GDC/pull/456) I thought I'd
try testing a more recent GDC with my STM32 demo
(https://github.com/JinShil/stm32f42_discovery_demo) and see what
the state of thing
28 matches
Mail list logo
