search for: jobnoorman

I have a question about the performance of the implementation of the stack protector in LLVM. Consider the following C program: ===== void canary() { char buf[20]; buf[0]++; } int main() { int i; for (i = 0; i < 1000000000; ++i) canary(); return 0; } ===== This should definately run slower when stack protection is enabled, right? I have measured the runtime of

If you compile this with optimizations, then the 'canary()' function should be totally inlined into the 'main()' function. In that case, the cost of the stack protectors will be very small compared to the loop. -bw On Mar 9, 2012, at 2:52 AM, Job Noorman <jobnoorman at gmail.com> wrote: > I have a question about the performance of the implementation of the stack > protector in LLVM. > > Consider the following C program: > ===== > void canary() > { > char buf[20]; > buf[0]++; > } > > int main() > { > int...

Hi, I'm trying to use analysis results from a CallGraphSCCPass in a ModulePass. Here is the relevant code: struct MyCallGraphSCCPass : CallGraphSCCPass { ... bool runOnSCC(CallGraphSCC& scc){...} }; char MyCallGraphSCCPass::ID = 0; static RegisterPass<MyCallGraphSCCPass> X("cgscc", "Dummy CG SCC pass"); struct MyModulePass : public ModulePass {

I have noticed that dragonegg sometimes allocates stack objects in a different order than they were declared in the source file. I experienced this behavior when compiling RIPE (https://github.com/johnwilander/RIPE) in the function perform_attack. Unfortunately, I haven't been able to reproduce this in a minimal example. (Note that when compiling RIPE with GCC, the order of stack

Hi Duncan, > I think this is probably due to stack variables being output lazily, i.e. > when first used. For example, if you declare variables A and B but use B > first then probably B will get output to the LLVM IR first. I think you're right: I fixed my particular problem by initializing all stack variables. > I guess I could arrange for them all to be output in one fell

I'm writing an opt pass that adds a lot of new functions to a module. In some extreme cases, this causes opt to fail with out-of-memory errors. Since all the created functions quickly become unneeded for my pass, I am trying to find a way to discard them from memory (i.e., write them to disk). I noticed there is a method to do just this: GlobalValue::Dematerialize. However, there does not

Hi Andrew, While working on the MSP430 backend, I noticed code that compiled fine before hitting an assert which you have recently inserted in r184574. More specifically, in InlineSpiller.cpp:1076 the following assert is triggered: > assert(MO->isDead() && "Cannot fold physreg def"); I wouldn't be surprised is the underlying cause is in the MSP430 backend but I

I'm currently working on the MSP430 backend and I have some problems implementing the calling convention. It's a 16-bit architecture which dictates that arguments should be passed in registers R15-R12. Therefore, I have something like this is a .td file: CCIfType<[i16], CCAssignToReg<[R15W, R14W, R13W, R12W]>> 32-bit arguments should be passed in R14:R15 (R12:R13).