similar to: [LLVMdev] Safe loads

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 >

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 >>

Hi, There are several optimizations where we try to load speculatively. There are also two similar functions to determine whether it's a safe transformation: * isSafeToLoadUnconditionally * isSafeToSpeculativelyExecute isSafeToLoadUnconditionally tries to take load alignment into account but fails to do this in some cases. It checks alignment for pointers derived from allocas and global

Given a pointer, does any addrspacecast affect the pointer's dereferenceablity ? For example, %pm = addrspaacecast float addrspacecast(n)* %pn to float addrspacecast(m)* %r = load float addrspace(m)* %pm In another word. the question is whether the following is true ? isDereferenceablePointer(pn) == isDereferenceablePointer(pm) [Note that the function is defined as

Hello, Currently, llvm::isSafeToSpeculativelyExecute() always returns false for Call instructions. This has actual performance implications, because loop-invariant code motion makes this check, and will never hoist instructions that are not safe to speculatively execute. Unfortunately, there is currently no way to signal to LICM that a function is safe to speculatively execute. The

everyone-- File this under Advocacy. See this thread <http://www.haskell.org/pipermail/glasgow-haskell-users/2010-February/018425.html> for more information, but the short summary is that they're deprecating their old "compile to GCC" backend in favor of David Terei's new LLVM backend. They're still planning for their C-- backend to be the primary backend for native

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

I'm spec-ing a development server for some Haskell hackers. In particular, they need to be able to build and run the Glasgow Haskell Compiler (ghc), the x86_64 port of which isn't quite there yet. My current thought is to get an Opteron-based system, but load it (initially, at least) with the 32-bit i386 version of CentOS. That buys me near-term ghc compatibility. In the future,

I've just noticed this, in Instruction::isSafeToSpeculativelyExecute(): http://llvm.org/doxygen/Instruction_8cpp-source.html#l00408 00430 case Load: { 00431 if (cast<LoadInst>(this)->isVolatile()) 00432 return false; 00433 if (isa<AllocaInst>(getOperand(0)) || isMalloc(getOperand(0))) 00434 return true; This says that it's safe to speculatively

2011/12/14 Rafael Ávila de Espíndola <rafael.espindola at gmail.com>: >> We first perform a speculation transformation, hoisting all of the >> code above the %overflow_check branch: >> >>   %t0 = add nsw i32 %a, %b >>   %t1 = sext i32 %t0 to i64 >>   %t2 = ashr i64 %t1, 31 >>   %t3 = add i64 %t2, 1 >>   %t5 = icmp ult %t3, 2 >>   %t6 =

Hi All, The Glasgow Haskell compiler has recently become an external user of LLVM. You can read about it here: http://blog.llvm.org/2010/05/glasgow-haskell-compiler-and-llvm.html If you have any comments, questions or perhaps even advice on solving some of the issues that need to be fixed in the backend going forward then please reply to this email. Cheers, David

Hi, I'm writing a custom alias analyser for the Glasgow Haskell Compiler's LLVM backend to teach LLVM that our explicitly-represented stack cannot alias with any heap pointer. It works, but I've hit an issue with opt's handling of alias analysers; if you specify -ghc-aa on the opt command line then LLVM only uses that analyser until (I think) a pass runs that invalidates the

On Aug 19, 2012, at 2:55 PM, "Kuperstein, Michael M" <michael.m.kuperstein at intel.com> wrote: > Hello, > > Currently, llvm::isSafeToSpeculativelyExecute() always returns false for Call instructions. > This has actual performance implications, because loop-invariant code motion makes this check, and will never hoist instructions that are not safe to speculatively

Hi Nadav, On 08/09/12 22:51, Nadav Rotem wrote: > > On Aug 19, 2012, at 2:55 PM, "Kuperstein, Michael M" > <michael.m.kuperstein at intel.com <mailto:michael.m.kuperstein at intel.com>> wrote: > >> Hello, >> Currently, llvm::isSafeToSpeculativelyExecute() always returns false for Call >> instructions. >> This has actual performance

Hi, Right now in LICM (and many other transformations) we always assume it is never safe to speculatively execute a function call. The following function always return false for all function calls except for few intrinsics: bool llvm::isSafeToSpeculativelyExecute(const Value *V, const DataLayout *TD) { ... case Instruction::Call: { if (const

I'm losing my sanity, so I thought I'd try and generate an LLVM target for the Glasgow Haskell Compiler (GHC). In talking to some of the people in the GHC mailing list some issues have come up that I can't find a ready answer to. (Others came up that I could, so I don't feel quite as stupid or helpless as I could.) 1. Is there any way to hint that a global pointer variable

Hi All, The GHC developers would like to add support to llvm to enable the order that code and data are laid out in, in the resulting assembly code produced by llvm to be defined by the user. The reason we would like to have this feature is explained in the blog post on GHC's use of llvm here: http://blog.llvm.org/2010/05/glasgow-haskell-compiler-and-llvm.html, specifically under the title,

A patch is attached. Not sure I'm happy with this due to the aforementioned orthogonality concerns, but I really don't have any better ideas. If anyone does, feel free to offer them, I don't mind throwing this patch into the trash. (Also, not happy with the name, using "speculatable" as Nick suggested, for the lack of other options. If the name stays I'll add it to the

Hi all, When I use Clang, I can add -mno-thumb to the command line and Clang generates pure Arm code without any use of Thumb instructions. However, I am messing about with the Glasgow Haskell Compiler (GHC) which generates LLVM IR code directly and then calls `opt` and `llc` on that IR code. The generated IR code currently has: target datalayout =

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