Accessing peripheral registers - the next version

Johannes Pfau via D.gnu d.gnu at puremagic.com
Sat Sep 24 01:14:03 PDT 2016


Am Wed, 31 Aug 2016 12:28:58 +0000
schrieb Timo Sintonen <t.sintonen at luukku.com>:

> On Wednesday, 31 August 2016 at 10:12:21 UTC, Johannes Pfau wrote:
> > Am Wed, 31 Aug 2016 09:07:49 +0000
> > schrieb Timo Sintonen <t.sintonen at luukku.com>:
> >
> >  
> >> 
> >> The original functions had force_inline attribute. The 
> >> compiler said it can not inline because the body is not 
> >> available. Is this because they are templates or is this 
> >> because of the intrinsic call? These calls are often in time 
> >> critical places and inlining them is very important.
> >>   
> >
> > This is probably a old GDC/DMDFE bug. Cross-module inlining 
> > (i.e. function with force-inline in one module, caller in 
> > another module) wasn't possible with older frontend versions. 
> > It should be possible now, but it is not implemented in GDC. 
> > Can you post a simple test case? Usually templated methods are 
> > the only methods which should work with cross module inlining.
> >  
> Anything that access the Volatile members:
> 
> int test()
> { return uart3.sr; }
> 
> error: inlining failed in call to always_inline 'load': function 
> body not available
> T load @property { return volatileLoad(&raw); }
> 
> 

Sorry, it took me some time to get back to this. Anyway, forceinline
works for me if I use it in the same module:
https://paste.gnome.org/p1nlnvagl

If I instead move the main function to a different file, I can
reproduce the error. This is the known cross-module inlining problem.
I'll probably have a look at this soon.
https://forum.dlang.org/post/mzevpbxsyvdrcyjuwhuu@forum.dlang.org


More information about the D.gnu mailing list