On Saturday, 20 May 2017 at 11:34:55 UTC, 9il wrote:
On Saturday, 20 May 2017 at 11:30:54 UTC, John Colvin wrote:
On Saturday, 20 May 2017 at 03:24:41 UTC, 9il wrote:
Hello,
When users write math code, they expect [2, 3, 4] that the
code like
[...]
What you are saying is that there is a specific shortcoming
that you are observing in optimisers, yes? Perhaps we should
investigate how to fix the optimisers first before insisting
on language additions / changes.
Have you talked to someone with experience writing optimisers
about what stops the relevant optimisation being done after
inlining?
I just found that new LLVM solves this issue (and was very
surprised).
The reason that ndslice <=v0.6.1 was so slow is LDC Issue 2121.
I have added workaround in [2], it is v0.6.2.
[1] https://github.com/ldc-developers/ldc/issues/2121
[2] https://github.com/libmir/mir-algorithm/pull/41
What's surprising about it? Thinking very simplistically (I
don't know how it actually works), if inlining happened first
then surely the later optimisation stages wouldn't have a problem
detecting the necessary loop invariants and hoisting them out.
