Re: Fat references

Jon Harrop <>
Wed, 06 Jan 2010 02:08:14 +0000

          From comp.compilers

Related articles
[25 earlier articles]
Re: Fat references (Kaz Kylheku) (2010-01-04)
Re: Fat references (Jon Harrop) (2010-01-05)
Re: Fat references (Dennis Ritchie) (2010-01-05)
Re: Fat references (Kaz Kylheku) (2010-01-05)
Re: Fat references (BGB / cr88192) (2010-01-05)
Re: Fat references (Jon Harrop) (2010-01-06)
Re: Fat references (Jon Harrop) (2010-01-06)
Re: Fat references (George Neuner) (2010-01-07)
Re: Fat references (George Neuner) (2010-01-07)
Re: Fat references (George Neuner) (2010-01-07)
| List of all articles for this month |

From: Jon Harrop <>
Newsgroups: comp.compilers
Date: Wed, 06 Jan 2010 02:08:14 +0000
Organization: Flying Frog Consultancy Ltd.
References: 09-12-045 09-12-055 10-01-005 10-01-031
Keywords: VM, code
Posted-Date: 08 Jan 2010 10:18:38 EST

Kaz Kylheku wrote:
> Are any of your benchmarks structured as a realistic program with
> function calls going around among separately compiled external module
> (and possibly separately loaded at run-time?)

There is no notion of external module. HLVM uses JIT compilation to
perform whole-program optimization on-the-fly, like the CLR.

> How much leverage are you getting in the benchmarks from just
> accessing those parts of the reference that are relevant to the
> computation (such as the principal pointer to the underlying data),
> avoiding situations where you have to load the whole thing?

Difficult to say. LLVM's optimization passes optimize such things but
generally do not improve performance.

> In real-world programs, there do end up copies of references to heap
> data. Even if the heap itself doesn't have multiple references to an
> object (i.e. most objects in the heap have a unique parent object in
> the heap), the program can still be juggling lots of copies in the
> registers, and throughout the call stack, whose frames may be spread
> among external functions.


> Some copies may not even be semantic references. If a function needs
> to save some callee-saved registers to backing memory and re-load
> them, a copy is made twice, even though the backing memory has no
> semantic role other than holding those registers. Fat references will
> create more register pressure of this type.

In theory, yes.

> Say you need a whole bunch of registers to load some fat references
> from memory. Oops, you've run out of the callee-clobbered registers,
> and need to use callee-saved ones. So now your function has to save
> those to memory and then restore them before returning. You've just
> copied the parent frame's data twice, even though you aren't working
> with that data.

That's the concern but it seems to be unfounded in practice.

Dr Jon D Harrop, Flying Frog Consultancy Ltd.

Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.