On Sat, 11 Nov 2006, Jeff Garzik wrote:
> Given the following C code:
>
> #include <stdlib.h>
>
> int foo(void)
> {
> int i;
>
> i = 42;
> i += rand();
>
> return i;
> }
>
> test-linearize seems to give me the following output, which indicates that
> pseudo %r1 is "dead" immediately before it is used:
That is normal.
"dead X" means that X is dead after the _next_ (non-deathnote)
instruction.
So every single death-note should always show up _before_ an instruction
that uses that register, or something is wrong.
This is actually very useful. It means that for a code generator that
keeps track of hardware registers, it knows that a register content can be
re-used as the _destination_ of a code sequence when it sees the
death-note.
So for example:
> foo:
> .L0x2b52beecd010:
> <entry-point>
> call.32 %r1 <- rand
> dead %r1
> add.32 %r4 <- %r1, $42
> dead %r4
> ret.32 %r4
Here, the compiler back-end might, for example, look at
call.32 %r1 <- rand
and decide to use register %eax for %r1.
Now, the "dead %r1" that follows will tell the back-end that the value in
%r1 will be used _only_ by the following instruction, and never again, so
when it sees the
add.32 %r4 <- r1, $42
the back-end can trivially decide to _reuse_ %eax for %r4 too, and
generate just a simple
addl $42,%eax
for that instruction, without worrying at all about the fact that it
over-writes the register that contains %r1.
The same thing foes for the next two instructions: "dead %r4" means that
r4 (which we hold in %eax) will be dead after the next instruction (the
return), so again it knows that it can re-use %eax for the result. Of
course, for a return that's trivial anyway, but..
My "example" back-end actually does all this. It's buggy as hell, but try
./example file.c
on your input file, and at least I get:
.globl foo
foo:
call rand # generate_call
add.32 $42,%eax # do_binop
ret # generate_ret
which actually is correct (and re-uses %eax all the time). It even gets a
few more complicated cases right, but there are certainly trivial ways to
confuse it too (it doesn't really do any stack slot allocation, so
anything that generates a spill - which it _will_ try to do - will
actually generate completely broken code that just overwrites the stack).
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-sparse" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
