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