Re: Hoopl vs LLVM?

Simon Marlow <[email protected]>
Newsgroups gmane.comp.lang.haskell.cvs.ghc,gmane.comp.lang.haskell.glasgow.user
Message-ID <[email protected]>
On 11/12/12 21:33, Johan Tibell wrote:
> On Tue, Dec 11, 2012 at 11:16 AM, Simon Peyton-Jones
> <[email protected]> wrote:
>> Notice that the stack is now *explicit* rather than implicit, and LLVM has no hope of moving the assignment to z past the call to g (which is trivial in the original).  I can explain WHY we do this (there is stuff on the wiki) but the fact is that we do, and it's no accident.
>
> I'd definitely be interesting in understanding why as it, like you
> say, makes it harder for LLVM to understand what our code does and
> optimize it well.

The example that Simon gave is a good illustration:

	f() {
		x = blah
		z = blah2
		p,q = g(x)
		res = z + p - q
		return res
	}

In this function, for example, a Hoopl pass would be able to derive 
something about the value of z from its assignment (blah2), and use that 
information in the assignment to res, e.g. for constant propagation, or 
more powerful partial value optimisations.

However, the code that LLVM sees will look like this:

	f () {
		x = blah
		z = blah2
                 Sp[8] = z
		jump g(x)
	}

	fr1( p,q ) {
                 z = Sp[8];
		res = z + p - q
		return res
	}

Now, all that LLVM knows is that z was read from Sp[8], it has no more 
information about its value.

Cheers,
	Simon
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.