search for: jobnoorman

Displaying 8 results from an estimated 8 matches for "jobnoorman".

2012 Mar 09
3
[LLVMdev] Stack protector performance
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
2012 Mar 10
0
[LLVMdev] Stack protector performance
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...
2011 Oct 10
0
[LLVMdev] Using analysis results from a CallGraphSCCPass in a ModulePass
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 {
2012 Mar 15
1
[LLVMdev] Dragonegg stack variables reorderings
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
2012 Mar 15
2
[LLVMdev] Dragonegg stack variables reorderings
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
2012 Mar 18
0
[LLVMdev] Dematerializing functions during opt
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
2013 Jul 15
0
[LLVMdev] Question about LLVM r184574
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
2012 Nov 27
2
[LLVMdev] Problem selecting the correct registers for a calling convention
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).