On 08/28/2011 01:16 AM, Pekka Enberg wrote:
On Sat, 27 Aug 2011, Jeff Garzik wrote:
OK, I lied. Function call support (OP_CALL) sent your way via github
pull request.
Pulled, thanks!
(added list to CC)
Just sent another, tiny pull req. That's it for tonight.
Random thoughts / backend status:
* it will soon be necessary to pay more attention to target-specific
details. we need some mechanism for specifying i386, x86-64, etc. so
that we may fill in bits_in_pointer and similar values properly. This
may involve some sparse hacking IIRC, because sparse (used to be?)
largely hardcoded to use i386 target values when checking. Or maybe
this is already done, and I just am ignorant of that area of the code.
* playing with some simple loop test cases, we are blocked on properly
listing out all phi's in an OP_PHI. sparse correctly sends us
OP_PHISOURCE, and test-linearize output looks good, but if the phisrc is
from a succeeding basic block, we may lack 'priv' necessary to fill in
LLVMValueRef required by LLVM phi machinery.
* my development workflow is very simple. create testcase; look at
test-linearize output; observe how linearize.c's show_instruction() and
show_pseudo() walk their data structures; copy this into sparse-llvm.
* it would be nice to get "printf(hello world)" working all the way
through sparsec.
* need to start integrating struct support. LLVM has a type system
where one defines data structures in the IR, then uses 'getelementptr'
LLVM instruction to build addresses for complex load/store operations.
The Linux kernel uses a lot of function calls (indirect branches) from
values buried deep within a struct.
--
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
