poor codegen for abs(), and div by literal?

[H. S. Teoh]

On Thu, Feb 07, 2019 at 11:15:08PM +0000, NaN via Digitalmars-d wrote:
> Given the following code...
[...]
> the compiler outputs the following for the function body, (excluding
> prolog and epilogue code)...
[...]
> So to do the abs(), it stores to memory from XMM reg, loads into x87
> FPU regs, does the abs with the old FPU instruction, then for some
> reason stores the result as a double, loads that back into an XMM,
> converts it back to single.

Which compiler are you using?

For performance / codegen quality issues, I highly recommend looking at
the output of ldc or gdc, rather than dmd.  It's well-known that dmd
codegen tends to lag behind ldc/gdc as far as efficiency / optimization
is concerned.  These days, I don't even look at dmd output anymore when
I'm looking for performance.  IME, dmd consistently produces code that's
about 20-30% slower than ldc or gdc produced code, sometimes even as
high as 40%.


> And the div by 3.142f, is there a reason it cant be converted to a
> multiply?  I know I can coax the multiply by doing *(1.0f/3.142f)
> instead, but I wondered if there's some reasoning in why its not done
> automatically?
> 
> Is any of this worth add to the bug tracker?

If this problem is specific to dmd, you can post a bug against dmd, I
suppose, but I wouldn't hold my breath for dmd codegen to significantly
improve in the near future.  Walter is far too overloaded with other
language issues to do significant work on the optimizer at the moment.

OTOH, when it comes to floating-point operations, the optimizer's hands
may be tied because of IEEE 754 dictated semantics. There may be some
corner cases where multiplying rather than dividing may produce
different results, and therefore the optimizer is not free to simply
substitute one for the other, even if in this case it works fine.  You
may need to spell it out yourself if what you want is a multiply rather
than a divide.


T

-- 
IBM = I'll Buy Microsoft!