On Wednesday, 17 August 2016 12:00:46 UTC-4, HWJ wrote:
>
> TL;DR: what's the best way to do SSA back-translation when using
> x/tools/go/ssa?
>
> I'm thinking about a Go compiler which accepts a subset of Go and emits
> assembly for a microcontroller. Instead of going all the way from
> lexing
>
> My primary question is whether I should transform ssa.Value into another
> type that allows SSA transformation (register renaming etc.) or if
> there's a chance the x/tools/go/ssa package will be extended to allow
> this.
>
The x/tools/go/ssa package exists to do static analysis, so SSA
My experience in TARDISgo was that Name() was stable and correct,
see
https://github.com/tardisgo/tardisgo/blob/89fb026cf24627db3bddabb754fed9500b5cabcd/haxe/base.go#L62
Good to know, thanks for sharing.
My primary question is whether I should transform ssa.Value into another
type that allows
>
>
> In order to generate assembly code I need to remove the Phi functions
> and rename the registers accordingly. The register field in SSA is not
> exported and can be accessed read-only by Name(). This makes SSA
> back-translation cumbersome.
>
My experience in TARDISgo was that Name() wa
