search for: lctes

...whole-program compilation of embedded codes using LLVM. The transformations that are most interesting to me are those that do not make sense (and hence, have not been explored deeply) by the general-purpose compiler community. A good example is getting rid of the call stack (we have an upcoming LCTES paper about this). Clearly it's stupid to do this for Firefox or MSWord, but it can win for microcontroller codes. Our prototype was partially via source-to-source transformation, partially via gcc hacks. Overall this was not very fun-- we should have done the work in LLVM (but nobody wro...

...inal implementation (llvm 2.1). we've used the ARM backend for evaluation and obtained quite encouraging results: speedups are up to 10% for SPEC/Mibench and up to 57% for simple loop kernels. the compile time increase is about a factor of 2. the paper has been accepted for this year's LCTES conference (june 12-13, tucson, az). i'm afraid i cannot post it on the list but i'm happy to send a preliminary version to anybody who's interested. the implementation is not yet as efficient as it could be (e.g., we maintain an additional datastructure for the ssa graph along with...

...memory safety could be enforced without *any* run-time checks or GC. We found that array bounds checks were the biggest problem; ignoring these, we can ensure the safety of pointer and dynamic memory usage in all the embedded benchmarks we tried without any run-time checks. The paper appeared at LCTES: http://llvm.org/pubs/2003-05-05-LCTES03-CodeSafety.html Like the later work, this did not eliminate use-after-free but used APA to ensure that any use-after-free errors are “harmless” in that they did not violate all the other type- and memory-safety guarantees. Let me know if you have any quest...

John, We (more accurately, John Criswell and Brice Lin) are working on a debugging version of SAFECode right now, which should be robust enough to play with soon. What kinds of embedded codes do you have in mind? One of our goals has been to minimize or even eliminate run-time checks for embedded code that meets certain restrictions. You can see the following paper for more details:

SVA/safecode looks interesting. Is it available to play with? I grepped for strings such as "sva" "secure" "safecode" in the LLVM source tree and didn't find anything, nor did I see obvious links to implementations from the project web pages. In the short term, questions I'd be interested in answering are: What happens when embedded codes that I care

...; embedded codes using LLVM. The transformations that are most > interesting to me are those that do not make sense (and hence, have > not > been explored deeply) by the general-purpose compiler community. A > good example is getting rid of the call stack (we have an upcoming > LCTES > paper about this). Clearly it's stupid to do this for Firefox or > MSWord, but it can win for microcontroller codes. Our prototype was > partially via source-to-source transformation, partially via gcc > hacks. Overall this was not very fun-- we should have done the work >...

...d the ARM backend for evaluation > and > obtained quite encouraging results: speedups are up to 10% for > SPEC/Mibench and up to 57% for simple loop kernels. the compile time > increase is about a factor of 2. Very nice! > > > the paper has been accepted for this year's LCTES conference (june > 12-13, tucson, az). i'm afraid i cannot post it on the list but i'm > happy to send a preliminary version to anybody who's interested. > > the implementation is not yet as efficient as it could be (e.g., we > maintain an additional datastructure for the...

On Mar 24, 2008, at 10:47 PM, Christopher Lamb wrote: > I know that this has been discussed (at least in passing) a few > times on the list, but I couldn't locate a bug for it. Have any > architectural plans been made for it? Funny you bring this up. Evan and I were tossing around crazy ideas about this just today. If you're interested, maybe we should get together for

I know that this has been discussed (at least in passing) a few times on the list, but I couldn't locate a bug for it. Have any architectural plans been made for it? Are there architectural roadblocks with the current LLVM infrastructure that will complicate the process? What has demotivated the implementation of this so far (is it not that big a benefit on important targets, too