similar to: [LLVMdev] possible addrspacecast problem

I'm have a [PATCH] isDereferenceablePointer: look through gc.relocates and I want to know how to test this patch. So far, I've found one candiate: speculative execution in SimplifyCFG (test/Transforms/SimplifyCFG/SpeculativeExec.ll). However, it's somewhat involved to show that SimplifyCFG does kick in for gc.relocate. Is there a better way to directly test it? Signed-off-by:

Philip Reames wrote: > T.M.K., there's no direct way to test it. There is. See the 'unittests/' directory which contains the C++ unit tests. See unittests/IR/UserTest.cpp for an example that builds up IR from a .ll-in-a-C-string then queries C++ API operations on it. Nick You have to construct a > transformation which happens with the information you added and not >

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

Hi, I've been debugging this issue for many hours, and would like a sanity check. The issue is that DL (DataLayout) is nullptr inside isDereferenceablePointer() no matter what I try. Why is DataLayout ever nullptr (shouldn't it get defaults?), and what should I do to make it non-nullptr? Thanks. Ram

Hello, I was wondering how you can identify whether or not an Argument is a pointer. The "isDereferenceablePointer" function for Values doesn't seem to be what I want (I don't care whether or not the pointer points to allocated memory or is suitably aligned). I want to be able to discern between: i32* %pArray and i32 %pArray Thanks in advance. - John

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

You can use isPointerTy() in Type class. George On Mon, Aug 20, 2012 at 12:39 PM, John Backes <back0145 at umn.edu> wrote: > Hello, > > I was wondering how you can identify whether or not an Argument is a > pointer. The "isDereferenceablePointer" function for Values doesn't > seem to be what I want (I don't care whether or not the pointer points > to

On Dec 14, 2011, at 12:11 PM, Eli Friedman wrote: > 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

> LICM on ToT hoists the div. Even speculatively. > > The other thing is that div is just one example. The problem could > also come up with an array load with an index could be safe to > speculate if the index is known to be bounded. isDereferenceablePointer > currently doesn't know how to do this, but it'll probably get > smarter some day. So, looking at just this

Eric Christopher wrote: > How are you trying to call it? Do you have a DataLayout? In test/Analysis/ValueTracking/memory-dereferenceable.ll, just change byval to dereferenceable(8), and %dparam won't match (see lib/IR/Value.cpp:521 for the logic that is supposed to fire). How do I get it to pass? I tried introducing a target-triple and target-datalayout, but it didn't help.

This is a follow-up discussion on http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20140324/101899.html. The front-end change was already pushed in r204677, so we want to continue with the IR optimization. In general, we want to write an IR pass to convert generic address space usage to non-generic address space usage, because accessing the generic address space in CUDA and OpenCL is

From: Villmow, Micah Sent: Tuesday, September 11, 2012 12:51 PM To: llvm-commits at cs.uiuc.edu Subject: Proposal: New IR instruction for casting between address spaces Problem: Bit casting between pointers of different address spaces only works if all address space pointers are the same size. With changes from email chain [1][2], support for different pointer sizes breaks the bitcast instruction

On Tue, Mar 25, 2014 at 3:21 PM, Matt Arsenault <Matthew.Arsenault at amd.com>wrote: > On 03/25/2014 02:31 PM, Jingyue Wu wrote: > > > However, we have three concerns on this: > a) I doubt this optimization is valid for all targets, because LLVM > language reference ( > http://llvm.org/docs/LangRef.html#addrspacecast-to-instruction) says > addrspacecast "can be

Hi Mehdi, Thanks for the reply - I’ve finally got round to trying to fix this based on your suggestion. I’ve got something that mostly works, but I just wanted to double-check something about the regression tests before I post a patch. > The memcpy is supposed to be equivalent to a sequence of load and store. Here we are just failing to keep the property that the load is performed through

Hi all, the addrspacecast stuff has landed and I'm now seeing failures in our back end because clang is emitting them, they're travelling through the IR to the SelectionDAG, and there's nothing to match them. Trying to match them, I get an error from TableGen saying: Variable not defined: 'addrspacecast' If I try to set a custom OperationAction in the target lowering class

OK, I’ve hit one more existing regression test that I’m weary of: define void @test2_addrspacecast() { %A = alloca %T %B = alloca %T %a = addrspacecast %T* %A to i8 addrspace(1)* %b = addrspacecast %T* %B to i8 addrspace(1)* call void @llvm.memcpy.p1i8.p0i8.i64(i8 addrspace(1)* %a, i8* bitcast (%T* @G to i8*), i64 124, i32 4, i1 false) call void

> -----Original Message----- > From: Dan Gohman [mailto:gohman at apple.com] > Sent: Tuesday, September 11, 2012 1:28 PM > To: Villmow, Micah > Cc: llvmdev at cs.uiuc.edu > Subject: Re: [LLVMdev] Proposal: New IR instruction for casting between > address spaces > > On Sep 11, 2012, at 1:03 PM, "Villmow, Micah" <Micah.Villmow at amd.com> > wrote: >

Hi, I'd like to add support for addrspacecast in initializers of global variables, at least for the trivial case. The trivial case is if TargetLowering::isNoopAddrSpaceCast(SrcAS, DestAS) returns true. In this case the MCExpr for the addrspacecast is the MCExpr of its first operand. It seems hard to obtain an instance of TargetLowering in AsmPrinter::lowerConstant(). Other methods in