ARM first & default LDC
Max Haughton
maxhaton at gmail.com
Wed Dec 30 17:47:55 UTC 2020
On Wednesday, 30 December 2020 at 16:53:41 UTC, Iain Buclaw wrote:
> On Wednesday, 30 December 2020 at 16:03:56 UTC, Max Haughton
> wrote:
>> On Wednesday, 30 December 2020 at 15:56:49 UTC, Ola Fosheim
>> Grøstad wrote:
>>> On Wednesday, 30 December 2020 at 15:00:15 UTC, Max Haughton
>>> wrote:
>>>> Cranelift already has basic ARM support too; I can't comment
>>>> on the quality of code generated.
>>>
>>> Are you thinking porting?
>>
>> No, just guessing how much work it would be. I would quite
>> like to get a basic backend going but it's much easier said
>> than done (i.e. most optimisations are fairly simple but
>> generating proper code and debug info at the end takes ages to
>> test let alone write)
>
> The dmd back-end is surprisingly more segregated than you
> think, there are a bunch of entrypoint methods you can override
> (class Obj if I remember correctly), and from there, modules
> can act as their own encapsulation for emitting code for
> different CPUs - just swap the x87 modules for ARM modules in a
> hypothetical build.
>
> Someone already did 70% of the work in untangling the back-end
> and made a toy ARMv4 backend several years ago. Though it may
> not be in a salvageable state now, especially if the ultimate
> aim is to generate code for the Apple M1.
I was more thinking of how (say) cgsched.d seems to basically
assume either a basic OoO or a pentium 5 UV pipeline. I don't
know empirically how sensitive a modern core is to instruction
scheduling given that a full Tomasulo-core actually makes it
relatively hard to force some kind of data hazards - as opposed
to an in-order pipeline.
Making that work with a generic machine is probably harder than
making a simple one from scratch (I'm not sure if cranelift
actually has a proper instruction scheduler)
If the actual object code and debug output could be reused reused
it would save a huge amount of work.
It would also be interesting to try and have a hard
cpu-instructions per IR-insn upper bound for debug builds.
More information about the Digitalmars-d
mailing list