Hi all, Greetings. I'm a Ph.D. student in UIUC. Now I'm working on SAFECode, a research compiler based on LLVM which insert necessary runtime checks to guarantee memory-safety of programs. SAFECode needs to insert checks into the programs (say, please check this load instruction for me). Currently SAFECode inserts these checks as normal call instructions. It would be great that LLVM can treat them as first-class intrinsics (like "llvm.ctz"), which have additional semantics and could be lowered as ordinary function calls in subsequent passes. This would be very useful because 1) It simplifies the analysis logic 2) LLVM can apply out-of-box compiler optimization technique way more easily on these programs (for example, SAFECode has special hacks to teach the LICM pass understand these runtime checks) 3) It completely avoid the naming conflicts between the tool and the program. Based on my observation, there are a number of research tools might have the same requirement above. For instance, Automatic Pool Allocation(PLDI'05), KLEE(OSDI'08) and SoftBound(PLDI'09) all insert special intrinsics into programs to perform domain-specific tasks. Having pluggable, first-class intrinsics would simplify the tasks a lot. I'm glad to dig in and implement it if you guys are interested. It seems to me that simply making llvm::CallInst inheritable would be enough. Comments and suggestions are highly appreciated. Thanks. Haohui
On Jun 12, 2009, at 2:52 PM, Mai, Haohui wrote:> Greetings. I'm a Ph.D. student in UIUC. Now I'm working on SAFECode, a > research compiler based on LLVM which insert necessary runtime checks > to guarantee memory-safety of programs. SAFECode needs to insert > checks > into the programs (say, please check this load instruction for me).Hi.> Currently SAFECode inserts these checks as normal call instructions. > It > would be great that LLVM can treat them as first-class intrinsics > (like > "llvm.ctz"), which have additional semantics and could be lowered as > ordinary function calls in subsequent passes.I was just about to recommend using normal function calls :).> This would be very useful because 1) It simplifies the analysis > logic 2) > LLVM can apply out-of-box compiler optimization technique way more > easily on these programs (for example, SAFECode has special hacks to > teach the LICM pass understand these runtime checks) 3) It completely > avoid the naming conflicts between the tool and the program.I don't follow. Why does it simplify the analysis logic? Also, aren't function attributes like "readonly" enough to teach the optimizer about your functions? -Chris
On Fri, 2009-06-12 at 16:16 -0700, Chris Lattner wrote:> On Jun 12, 2009, at 2:52 PM, Mai, Haohui wrote: > > Greetings. I'm a Ph.D. student in UIUC. Now I'm working on SAFECode, a > > research compiler based on LLVM which insert necessary runtime checks > > to guarantee memory-safety of programs. SAFECode needs to insert > > checks > > into the programs (say, please check this load instruction for me). > > Hi. > > > Currently SAFECode inserts these checks as normal call instructions. > > It > > would be great that LLVM can treat them as first-class intrinsics > > (like > > "llvm.ctz"), which have additional semantics and could be lowered as > > ordinary function calls in subsequent passes. > > I was just about to recommend using normal function calls :). > > > This would be very useful because 1) It simplifies the analysis > > logic 2) > > LLVM can apply out-of-box compiler optimization technique way more > > easily on these programs (for example, SAFECode has special hacks to > > teach the LICM pass understand these runtime checks) 3) It completely > > avoid the naming conflicts between the tool and the program. > > I don't follow. Why does it simplify the analysis logic? Also, > aren't function attributes like "readonly" enough to teach the > optimizer about your functions?In fact, they are not really "readonly" functions. These checking functions manipulate some metadata. If they are marked as readonly, ADCE will kill them. :-)> > -Chris > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev