Skip to content

testing: extend tests for register allocator #43

@mmcloughlin

Description

@mmcloughlin

We are reliant primarily on the examples for testing at this point. It would be good to "stress" the allocator because I would be (pleasantly) surprised if it's bug-free.

  • More extensive unit testing
  • Integration test under tests/ that (for example) uses the max number of registers of a given kind and confirms the register allocator doesn't fall over
  • More specifically, handling of "casting" is a little ugly. It would be good to have a test that stresses this specifically. Perhaps, something that allocates 16 virtual general purpose registers and then accesses all sub-registers. This is clearly a possible allocation, but I could imagine the allocator messing up.
  • I'm sure other tests will come to mind

Unit tests right now are trivial:

avo/pass/alloc_test.go

Lines 9 to 46 in 7752262

func TestAllocatorSimple(t *testing.T) {
c := reg.NewCollection()
x, y := c.XMM(), c.YMM()
a, err := NewAllocatorForKind(reg.KindVector)
if err != nil {
t.Fatal(err)
}
a.Add(x)
a.Add(y)
a.AddInterference(x, y)
alloc, err := a.Allocate()
if err != nil {
t.Fatal(err)
}
t.Log(alloc)
if alloc[x] != reg.X0 || alloc[y] != reg.Y1 {
t.Fatalf("unexpected allocation")
}
}
func TestAllocatorImpossible(t *testing.T) {
a, err := NewAllocatorForKind(reg.KindVector)
if err != nil {
t.Fatal(err)
}
a.AddInterference(reg.X7, reg.Z7)
_, err = a.Allocate()
if err == nil {
t.Fatal("expected allocation error")
}
}

Metadata

Metadata

Assignees

No one assigned

    Labels

    good first issueGood for newcomerstestingTests and supporting infrastructure

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions