Christopher Li wrote:
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 :-).
I did not write test-parsing / show_symbol_list().
Use of test-parsing eliminates my code as a factor -- which was why I
mentioned it.
Oh well, I will figure it out.
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?
linearized output is too low level for LLVM in several cases. The
shifts in linearize_load_gen() and linearize_store_gen() get in the way,
for example. Having sparse calculate struct offsets itself is also not
desirable: in order to use LLVM's getelementptr instruction, you should
instead give LLVM the type information and member indices, and let it
figure out the address calculation from there.
Thus, use of linearize would imply having to work backwards and recreate
information lost during the linearization.
The general idea with LLVM bitcode is to pass it type information, and
it will ensure that bitfields are handled properly, structs are laid out
and padded properly, function return types handled, etc. LLVM handles
all the address generation for us, once we give it enough type info.
Jeff
--
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
