Menu
Search

Forums

Forum Index

Thread overview
LDC generate assembly unused instructions.
Apr 02, 2018
SrMordred
Apr 02, 2018
David Nadlinger
Apr 03, 2018
SrMordred
April 02, 2018
Gravatar of SrMordredPosted by SrMordredReply
SrMordred
Gravatar of SrMordred


Reply
(disclaimer: i'm a compiler noob)

https://godbolt.org/g/9QS3j4

Why LDC keep unused assembly code like
'example.Int.__mixin2.toHash' or 'example.Int.__mixin2.opBinary'
on the binary?
April 02, 2018
Gravatar of David NadlingerPosted by David Nadlinger
in reply to SrMordred		Reply
David Nadlinger
Gravatar of David Nadlinger
Posted in reply to SrMordred


Reply
On 2 Apr 2018, at 17:36, SrMordred via digitalmars-d-ldc wrote:
> Why LDC keep unused assembly code like
> 'example.Int.__mixin2.toHash' or 'example.Int.__mixin2.opBinary'
> on the binary?

In short, there is no way for the compiler to know whether they might be used from another module (object file).

They should disappear in the final executable on Linux (and I believe also Windows), though, if the linker does its job (--gc-sections).

 —David
April 03, 2018
Gravatar of SrMordredPosted by SrMordred
in reply to David Nadlinger		Reply
SrMordred
Gravatar of SrMordred
Posted in reply to David Nadlinger


Reply
On Monday, 2 April 2018 at 16:47:16 UTC, David Nadlinger wrote:
> On 2 Apr 2018, at 17:36, SrMordred via digitalmars-d-ldc wrote:
>> Why LDC keep unused assembly code like
>> 'example.Int.__mixin2.toHash' or 'example.Int.__mixin2.opBinary'
>> on the binary?
>
> In short, there is no way for the compiler to know whether they might be used from another module (object file).
>
> They should disappear in the final executable on Linux (and I believe also Windows), though, if the linker does its job (--gc-sections).
>
>  —David

Nice, Thanks!