Current GDC experience and questions

[Artur Skawina]

On 03/08/13 19:38, Iain Buclaw wrote:
> On 8 March 2013 18:19, Artur Skawina <art.08.09 at gmail.com <mailto:art.08.09 at gmail.com>> wrote:
> 
>     On 03/08/13 18:54, Iain Buclaw wrote:
>     > Also not needed:
>     > - aligned:  because D has align() for that.
> 
>     D's align wasn't nearly enough last time i looked. (There were changes to
>     it since, but as I can't upgrade, haven't looked at the details)
> 
>     > - gnu_inline, artificial:  because D has no inline keyword, nor has need for one.
> 
>     always_inline is needed, the heuristics are not always enough. Of course it
>     should map to just "inline".
> 
> 
> inline and always_inline are two subtly different beasts.  But altogether I don't think either make any guarantees of an inline occuring (although always_inline is a little more relaxed about it all).
> 
> Some things are marked as always_inline anyway by gdc:  struct/class methods, lambdas and delegate literals.  Though it is probably known that this only worked within the module being compiled.  Cross-module inlining is not there yet.

Really "always_inline"? IIRC gcc throws an error if can't inline a function marked
with that one - in fact that was one reason why i had to use @flatten instead of 
marking everything @always_inline - to avoid these errors. Things like methods
should not be marked as such, as they can be huge; the inlining heuristics should
be able to handle them.

>     > - pure, const:  Although D has pure keyword that does not necessarily follow same as C semantics, I don't think the inclusion of these are beneficial at all.
> 
>     "const" may not be needed. "pure" is useful /exactly/ because of the D semantics.
> 
> 
> Infact, strongly pure functions (where all parameters are immutable) are indeed marked as C "pure" by gdc if the functions are also nothrow.  Whether this might cause some bad behaviour I'm yet to run into or find a case of...

It's good to have a way to mark pure functions as such, D's pure doesn't help
when the args aren't immutable, but the code is pure /logically/.


>     > - optimise, target:  I'm sure the guy who implemented these meant well, but I fail to see the point as to why you'd want such an attribute.
> 
>     They are useful. And it reminds me that last time i looked, GDC handled "target", "tune"
>     etc wrongly: http://forum.dlang.org/post/mailman.1.1325716211.16222.digitalmars-d@puremagic.com
> 
> 
> And I'd rather not want to spend time fixing it.  The code that handles these attributes are a bit bulky, and require a bit of questionable copying from the c-family frontend.

Oh, I'm just mentioning this because marking some code to be compiled for one
cpu, and having other unrelated code be mistakenly built for that cpu can result
in nasty bugs. These attributes are useful, but there are easy workarounds,
like compiling the code separately, so supporting them can indeed be very low prio.

artur