globalRegMaybe and ARM

Simon Marlow marlowsd at gmail.com
Mon Aug 4 09:33:40 UTC 2014


Hi Ben,

There has been some confusion here because I accidentally committed a 
change to this file that then got reverted.  The original fix was #9055, 
making it so that on platforms with no registers, globalRegMaybe would 
return Nothing (as it should).  This wasn't necessary until recently 
when we started using globalRegMaybe during optimisation in CmmSink.

Yes I think you should add MACHREGS_arm to the #if in that file, and 
anywhere else where we do similar things.

Cheers,
Simon

On 23/07/2014 19:32, Ben Gamari wrote:
>
> Hello Simon,
>
> b0534f7 [1] and the subsequent reversion f0fcc41d7 touched
> `includes/CodeGen.Platform.hs`, the former removing a panic in the case
> of `globalRegMaybe` being undefined for a platform and replacing it with
> `Nothing`.
>
> Recently I've found that my ARM builds (with -fllvm) crash at this panic
> whereas they did not as of the 7.8 release. Given that b0534f7 was
> reverted this is no doubt due to another change that I haven't
> identified yet. Do you have any idea what is happening here?
>
> I'm currently attempting to build with a workaround setting
> `globalRegMaybe _ = Nothing`, although this smells suspicously like what
> would happen in the unregisterized case.
>
> My other hypothesis is that MACHREGS_arm should be added to the
>
>      #if MACHREGS_i386 || MACHREGS_x86_64 || MACHREGS_sparc || MACHREGS_powerpc
>
> which smells more like what a registerised architecture should do and it
> seems the requisite macros are defined for ARM in
> `stg/MachRegs.h`. Whatever happens for ARM should probably
> also happen for AArch64.
>
> How should `globalRegMaybe` and `freeReg` be defined for platforms that
> rely exclusively on the LLVM backend? Both ARM and AArch64 appear to be
> doing the wrong thing at present.
>
> Cheers,
>
> - Ben
>
>
> [1] https://github.com/ghc/ghc/commit/b0534f78a73f972e279eed4447a5687bd6a8308e#diff-4899eba6e173d5811d08d6c312da7752R741
>


More information about the ghc-devs mailing list