similar to: [LLVMdev] memory lifetime and invariance

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

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

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

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

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

Chris Lattner wrote: > 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 >>>>>

On Jan 23, 2012, at 4:22 AM, Roman Leshchinskiy wrote: > 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 >

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

On 24/01/2012, at 20:39, Chris Lattner wrote: > On Jan 23, 2012, at 4:22 AM, Roman Leshchinskiy wrote: > >> 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 >>

On Aug 17, 2011, at 5:02 AM, Matthieu Monrocq wrote: > My surprise stems from the fact that Clang/LLVM seems to reserve (at least in its bytecode) space for all temporary variables, not taking into account that some are mutually exclusive. I would have expected the space to be folded. However, since this is LLVM IR, and not the final assembly, and since LLVM IR is strongly typed, it makes

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

> On Dec 1, 2014, at 3:44 PM, Philip Reames <listmail at philipreames.com> wrote: > > (Spawning a separate subthread off the 'Optimization hints for "constant" loads' discussion for a related question. ) > > Looking at TBAA again, I was reminded that TBAA also contains a third field which indicates that "meaning pointsToConstantMemory should return

On Wed, May 20, 2009 at 1:29 PM, Chris Lattner <clattner at apple.com> wrote: >> The verifier rejects phi nodes of {} type. Do you actually have a case >> where you want this to happen? > > That sounds like a serious bug then: {} should be a first class value > just like {i32}. But in any case, it doesn't really make sense; wouldn't any value of type {} fold to

On May 23, 2009, at 12:04 PM, Nick Lewycky wrote: >> >> That sounds like a serious bug then: {} should be a first class value >> just like {i32}. > > Okay then. I've just posted a patch to llvm-commits which would do > that: > http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20090518/077934.html Why not separate the two patches: making {} legal

Chris Lattner wrote: > On May 23, 2009, at 12:04 PM, Nick Lewycky wrote: >>> That sounds like a serious bug then: {} should be a first class value >>> just like {i32}. >> Okay then. I've just posted a patch to llvm-commits which would do >> that: >> http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20090518/077934.html > > Why not

On May 23, 2009, at 1:47 PM, Nick Lewycky wrote: > Chris Lattner wrote: >> On May 23, 2009, at 12:04 PM, Nick Lewycky wrote: >>>> That sounds like a serious bug then: {} should be a first class >>>> value >>>> just like {i32}. >>> Okay then. I've just posted a patch to llvm-commits which would do >>> that: >>>

On Mar 6, 2006, at 4:05 PM, Chris Lattner wrote: > On Mon, 6 Mar 2006, John Criswell wrote: >> I was wondering if there is a standard way of specifying a list of >> functions that *should not* be inlined by the -inline pass. > > Nope, but you could hack something into gccas/gccld if you want. > Of course, you can disable inlining completely with the -disable- >

On Mon, Dec 3, 2018 at 11:49 PM John McCall <jmccall at apple.com> wrote: > Piotr's proposal unfortunately doesn't give us a good name for the class > of optimizations that require being listed in supported_optimizations. > In earlier discussions I called them "brittle", but I can understand why > nobody wants to call their optimization that, so let's call

> From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] On Behalf Of Hal Finkel via llvm-dev > Subject: Re: [llvm-dev] invariant.load metadata semantics > Alternatively, we might phrase this as: The optimizer may assume that all values loaded > from a location, where any of the loads are tagged with !invariant.load, are identical. This would seem to limit the usefulness of the

Sanjoy, can you clarify this bit about JVM array lengths? Presumably the same pointer can point to two arrays of different lengths during a program's execution. Does this mean that you're relying on invariant.load having function scope? That is, correctness depends on the pointer not being reused for an array of a different length between the first invariant load of that array length in