On Sun, Apr 26, 2009 at 1:52 PM, Jeff Garzik <jeff@xxxxxxxxxx> wrote:
>
> Consider this testcase:
>
> int bloo = 0;
>
> void inc_bloo(void)
> {
> bloo += 2;
> }
>
test-linearize show:
inc_bloo:
.L0x7fc013df7010:
<entry-point>
load.32 %r1 <- 0[bloo]
add.32 %r3 <- %r1, $2
store.32 %r3 -> 0[bloo]
ret
get_bloo:
.L0x7fc013df70a0:
<entry-point>
load.32 %r5 <- 0[bloo]
ret.32 %r5
> Any idea why? I'm not sure if this is a tree-walker bug or something from
> the parsing. The test-parse output is below...
So obvious the parser is correct and I will blame your code :-).
This bring the points that you really should make your LLVM converter
base on the linearized byte code. Being able to convert to LLVM
byte code is actually one of my consideration when I hack on the linearized
back end back then. Look, there is even reserved an opcode for
GET_ELEMENT_PTR. If there is some thing need to change to the linearized
back end to make this happen, I am glad to do it.
But I don't want to have yet another linearized equivalent code base in
sparse. This is duplicated effort. Bugs will need to fix in both place.
I am pretty sure using the linearized back end will greatly simplify
your LLVM byte code generation.
Do you want to give it a try?
Chris
--
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
