www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.ldc - Singleobj builds

reply Johan Engelen <j j.nl> writes:
Hi all,
   I just found this in mars.d:
```
   version (IN_LLVM)
   {
     if (global.params.oneobj && modules.dim < 2)
         global.params.oneobj = false;
```

Is there a special reason why `oneobj` is set to false when we 
only pass one D source file? For caching work, I want to know 
whether we are building stuff into one object file, and 
params.oneobj is apparently not what it says it is ;)

Thanks,
   Johan
Nov 01 2016
next sibling parent reply kinke <noone nowhere.com> writes:
On Tuesday, 1 November 2016 at 14:01:53 UTC, Johan Engelen wrote:

 Hi all,
   I just found this in mars.d:
 ```
   version (IN_LLVM)
   {
     if (global.params.oneobj && modules.dim < 2)
         global.params.oneobj = false;
 ```

 Is there a special reason why `oneobj` is set to false when we 
 only pass one D source file? For caching work, I want to know 
 whether we are building stuff into one object file, and 
 params.oneobj is apparently not what it says it is ;)

 Thanks,
   Johan


`-singleobj`, i.e., `global.params.oneobj`, does imply a few 
special cases. E.g., the single resulting object is always 
specified before all other existing object files when linking. 
The object filename may also differ if an output filename has 
been specified. For these reasons, I chose to clear that flag if 
the user has only specified a single D module to be compiled (and 
no `-main`, which implicitly adds a special source module), where 
-singleobj wouldn't make a semantic difference anyway.

This also makes sure `ldmd2 a.o b.d` results in the linking order 
`a.o b.o`.
Nov 01 2016
parent kinke <noone nowhere.com> writes:
Additionally, I think this works around a front-end bug wrt. 
inferred output filename if there are no source modules at all, 
i.e., when LDC/LDMD is only used for linking.
Nov 01 2016
prev sibling parent reply =?UTF-8?B?Tm9yZGzDtnc=?= <per.nordlow gmail.com> writes:
On Tuesday, 1 November 2016 at 14:01:53 UTC, Johan Engelen wrote:

 For caching work


Is there more IR-level caching work pending in LDC!?
Nov 07 2016
parent reply Johan Engelen <j j.nl> writes:
On Monday, 7 November 2016 at 22:17:33 UTC, Nordlöw wrote:

 On Tuesday, 1 November 2016 at 14:01:53 UTC, Johan Engelen 
 wrote:

 For caching work


 Is there more IR-level caching work pending in LDC!?


Source-level caching (`ccache`-like), it's almost done.

-Johan
Nov 07 2016
parent reply =?UTF-8?B?Tm9yZGzDtnc=?= <per.nordlow gmail.com> writes:
On Tuesday, 8 November 2016 at 05:15:56 UTC, Johan Engelen wrote:

 Source-level caching (`ccache`-like), it's almost done.


Sounds great. I presume (transitive) dependency analysis happens 
on file-level, right?

What is the motivation behind having this as well, when LDC just 
got IR-level caching aswell?
Nov 07 2016
parent Johan Engelen <j j.nl> writes:
On Tuesday, 8 November 2016 at 07:51:35 UTC, Nordlöw wrote:

 On Tuesday, 8 November 2016 at 05:15:56 UTC, Johan Engelen 
 wrote:

 Source-level caching (`ccache`-like), it's almost done.


 Sounds great. I presume (transitive) dependency analysis 
 happens on file-level, right?

 What is the motivation behind having this as well, when LDC 
 just got IR-level caching aswell?


It is approx. infinity times faster when the source has not 
changed. ;)
IR-level caching skips optimization and machine codegen.
Source-level caching also skips semantic analysis (which can take 
a considerable amount of time) and IR codegen+hashing (the 
hashing requires several seconds for large files).

See https://github.com/ldc-developers/ldc/pull/1871
I plan to write a small article explaining how it works when it 
is merged.

-Johan
Nov 08 2016