On 11/08/2011 07:35 PM, Martin Nowak wrote:
On Tue, 08 Nov 2011 09:08:49 +0100, Don <nos...@nospam.com> wrote:
On 07.11.2011 21:36, Martin Nowak wrote:
On Mon, 07 Nov 2011 20:42:17 +0100, Trass3r <u...@known.com> wrote:
version(ARM)
{
immutable X = armSpecificCode(); // you want to run this on an
X86???
}
I've always thought that it would be worthwhile to experiment with
LLVM's JIT engine here.
But as has been said quite some care will be necessary for cross
compilation.
Allowing arbitrary non-pure functions would cause lots troubles.
Yeah, I think JIT for CTFE would be *very* interesting. But mainly
for reasons of speed rather than functionality.
How would JIT work in the above case?
You would need to do JIT a target agnostic IR.
Yeah, it's only the glue layer which needs to change. The main
complexity is dealing with pointers.
Currently it only seems viable for strongly pure functions.
The JIT could just translate impure and unsafe constructs to
exceptions/errors being thrown (or similar). It would then work the same
way as it does now.
One would still need to be very careful about target dependencies
through libc calls (sinl et.al.),
marshalling the arguments and the result is necessary and dmd doesn't
have a virtual machine, does it?
One could try to fake the latter by compiling to executables, but it
would require a target specific runtime/stdlib.
Overall I don't have too much performance issues with CTFE.
I've more issues with badly scaling compiler algorithms now that they
are used with magnitudes bigger input, i.e. unrolled loops or huge array
literals.
Especially considering that they performance impact mostly stems from
codegen
and sometime the generated code is only used for compile time
initialization.
A lot of garbage is created during CTFE as in-place changes don't always
work.
For example I haven't yet succeeded in writing an in-place CTFE quicksort,
so I ended up with 'sort(left) ~ pivot ~ sort(right)'.
martin
