search for: memoryusemarkers

FYI, I wrote up some thoughts on this here: http://nondot.org/sabre/LLVMNotes/MemoryUseMarkers.txt The intention is to allow front-ends to express things like "I know this memory is a constant in this region" and to allow the optimizer/ codegen to perform more aggressive stack slot merging. -Chris

On May 19, 2009, at 12:32 AM, Nick Lewycky wrote: > Chris Lattner wrote: >> FYI, I wrote up some thoughts on this here: >> http://nondot.org/sabre/LLVMNotes/MemoryUseMarkers.txt >> >> The intention is to allow front-ends to express things like "I know >> this memory is a constant in this region" and to allow the optimizer/ >> codegen to perform more aggressive stack slot merging. > > Very nice! > > Why does @llvm.invariant....

On Mon, May 18, 2009 at 3:02 PM, Chris Lattner <clattner at apple.com> wrote: > FYI, I wrote up some thoughts on this here: > http://nondot.org/sabre/LLVMNotes/MemoryUseMarkers.txt > > The intention is to allow front-ends to express things like "I know > this memory is a constant in this region" and to allow the optimizer/ > codegen to perform more aggressive stack slot merging. It seems no more prone to abuse to reserve an address space for const m...

...of the loop"? If it is safe to move it anywhere (e.g. because it is a load from constant memory, the optimizer just doesn't know it) then using metadata makes sense. If it is a region where it is safe, then we'd need to implement something like this: http://nondot.org/sabre/LLVMNotes/MemoryUseMarkers.txt -Chris

Chris Lattner wrote: > FYI, I wrote up some thoughts on this here: > http://nondot.org/sabre/LLVMNotes/MemoryUseMarkers.txt > > The intention is to allow front-ends to express things like "I know > this memory is a constant in this region" and to allow the optimizer/ > codegen to perform more aggressive stack slot merging. Very nice! Why does @llvm.invariant.end restate the size when it a...

Chris Lattner wrote: > On May 19, 2009, at 12:32 AM, Nick Lewycky wrote: > >> Chris Lattner wrote: >>> FYI, I wrote up some thoughts on this here: >>> http://nondot.org/sabre/LLVMNotes/MemoryUseMarkers.txt >>> >>> The intention is to allow front-ends to express things like "I know >>> this memory is a constant in this region" and to allow the optimizer/ >>> codegen to perform more aggressive stack slot merging. >> Very nice! >> >> Wh...

...keep them separated. > > Therefore I was wondering if in the x86 representation (say) these would be folded, and if so what is the name of the Optimization/CodeGen pass responsible ? I commented on stack overflow. The rough plan of record is captured here: http://nondot.org/sabre/LLVMNotes/MemoryUseMarkers.txt The basic idea is that we capture the lifetime of the memory object in IR, then have the code generator allocate multiple alloca's with non-overlapping lifetimes to the same stack offset. -Chris -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://li...

Hello, For the Glasgow Haskell Compiler's backend, we would like to let LLVM know that certain loads are safe to execute speculatively and hence to hoist out of loops. At the moment, there doesn't seem to be a mechanism for doing so. There seem to be two ways of implementing this: either allow arbitrary instructions to be marked as safe and have Instruction::isSafeToSpeculativelyExecute

...e loop"? If it is safe to move it anywhere (e.g. because it is a load from constant memory, the optimizer just doesn't know it) then using metadata makes sense. If it is a region where it is safe, then we'd need to implement something like this: > http://nondot.org/sabre/LLVMNotes/MemoryUseMarkers.txt For the code that GHC generates, it is safe to load the pointer anywhere in the function that contains the load and those functions don't get inlined. But that's probably too specific to GHC, a general-purpose mechanism would make more sense. I looked at llvm.lifetime.start before but...

On May 19, 2009, at 7:58 PM, Nick Lewycky wrote: > Chris Lattner wrote: >> On May 19, 2009, at 12:32 AM, Nick Lewycky wrote: >> >>> Chris Lattner wrote: >>>> FYI, I wrote up some thoughts on this here: >>>> http://nondot.org/sabre/LLVMNotes/MemoryUseMarkers.txt >>>> >>>> The intention is to allow front-ends to express things like "I know >>>> this memory is a constant in this region" and to allow the >>>> optimizer/ >>>> codegen to perform more aggressive stack slot merging. >&...

Following a question on StackOverflow [1], I was wondering if for big allocations, LLVM would "delay" the allocation or rather perform it upfront. The following code was thus submitted to the LLVM Try Out page: void doSomething(char*,char*); void function(bool b) { char b1[1 * 1024]; if( b ) { char b2[1 * 1024]; doSomething(b1, b2); } else { char

...7:58 PM, Nick Lewycky wrote: > >> Chris Lattner wrote: >>> On May 19, 2009, at 12:32 AM, Nick Lewycky wrote: >>> >>>> Chris Lattner wrote: >>>>> FYI, I wrote up some thoughts on this here: >>>>> http://nondot.org/sabre/LLVMNotes/MemoryUseMarkers.txt >>>>> >>>>> The intention is to allow front-ends to express things like "I know >>>>> this memory is a constant in this region" and to allow the >>>>> optimizer/ >>>>> codegen to perform more aggressive stack...

...es. > Many thanks for your help, > Jim. Hi Jim, It's best to email llvmdev with general questions, as I get swamped and backlogged frequently. We don't have a good answer at present to the problem above, but I have some thoughts on the matter here: http://nondot.org/sabre/LLVMNotes/MemoryUseMarkers.txt We do currently have a hack in the inliner to reuse stack array memory that are inlined from different callees into a common caller. -Chris -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20110308/e58460...