Current GDC experience and questions

[Iain Buclaw]

On 8 March 2013 19:00, Artur Skawina <art.08.09 at gmail.com> wrote:

> 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/.
>
>
If the code is pure logically, it may be const folded away by the GCC
backend given correct circumstances.  However what we don't want to happen
is for it to accidentally optimise away a call that may alter an internal
state that affects runtime behaviour.


Regards
-- 
Iain Buclaw

*(p < e ? p++ : p) = (c & 0x0f) + '0';
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/d.gnu/attachments/20130308/3a489d8d/attachment.html>