Inlining asm functions

[Don]

bearophile wrote:
> While implementing some code I have seen that LDC (that uses Tango) isn't able to inline the code of expi, that is little more than a fsincos asm instruction. LDC is now able to inline sqrt, etc (that increases their efficiency a lot), but expi contains asm, and such functions aren't allowed to be inlined.
> 
> LDC has a way to allow such inlining of asm-containing functions anyway:
> pragma(allow_inline)
> 
> So I have seen my code get faster (with LDC) when I have used the following expi instead of the Tango one (I have removed the part that manages the case of no asm allowed because I was doing a quick test):
> 
> creal expi(real y) {
>     version (LDC) pragma(allow_inline);
> 	asm {           
> 		fld y;
> 		fsincos;
> 		fxch ST(1), ST(0);
> 	}
>     // add code here if asm isn't allowed
> }
> 
> Instead of just adding "version (LDC) pragma(allow_inline);" at the top of some Tango functions (array operations too can enjoy such inlining, because if you do a[]+b[] and their length is 4 there is a big overhead to call tango/Phobos functions), isn't it better to add to the D language something standard (= that works on DMD too) to state that some asm function can be inlined?
> (Generally the idea of porting back tiny things from LDC to DMD sounds nice, especially when DMD back-end is able to support them).

Nice idea, but it'd be pretty hard to do asm inlining in DMD. Consider 
that to get much benefit, it needs to get rid of the the "fld y". Tricky.

expi could be an intrinsic, it's the only place where fsincos would ever 
be used.

Array operations deserve to be treated specially when the length is 
known (and short). In trying to exterminate the internal compiler error 
bugs, I've been looking at the compiler's treatment of array ops over 
the past few days. There's a heap of room for improvement. (It's also 
one of the primary sources of bad code generation bugs).

> 
> Bye,
> bearophile