similar to: Bug in replaceUsesOfWith: does not keep addrspace consistent in GEP

On Sat, Aug 9, 2014 at 6:06 AM, Tim Northover <t.p.northover at gmail.com> wrote: > Hi Rob, > > On 9 August 2014 02:03, Rob Jansen <jansen at cs.umn.edu> wrote: > > Why is the first for loop not equivalent to the second? > > In the second loop, "*ui" is an llvm::Use object. It's owned by a > User, but isn't a subclass of one. To match the

> I think this is incorrect since the use_iterator is defined as: > > `typedef value_use_iterator<User> use_iterator;` > > and indeed `ui->getUser();` is not a callable function on a User. What am I > missing? Ah, looks like this has changed this year. What I said applies to trunk; you may be right there about 3.4 or earlier (looks plausible from the key commit).

Ahh ha! I believe that `User::replaceUsesOfWith` modifies the use list, which probably invalidated the use_iterator and caused my code to miss some of the uses. The following works great! (I'll spare you the details about what I am actually trying to do here, unless you really want to know more.) Thanks, Rob =========================== while(GV->getNumUses() > 0) { User* u =

Why is the first for loop not equivalent to the second? Thanks, Rob =========================== for (GlobalVariable **i = Globals.begin(), **e = Globals.end(); i != e; ++i) { GlobalVariable *GV = *i; Constant *GEP = ConstantExpr::getGetElementPtr(...); GV->replaceAllUsesWith(GEP); } =========================== for (GlobalVariable **i = Globals.begin(), **e = Globals.end(); i != e;

We'd like to be able to vary the latency of our load instructions based on what address space is being loaded from. I was thinking I could do this by overriding getOperandLatency in our target, but I'm wondering if the addrspace info is available when instructions are scheduled? For example, I have this in our llvm IR: %0 = load i32 addrspace(4)* @answer, align 4 store i32 %0, i32*

I am slightly unclear about the semantics of the addrspace attribute and there use with intrinsics. For example, is the following code valid: %ptr = malloc i32 addrspace(11) %result = call i32 @llvm.atomic.load.add.i32( i32 addrspace(11)* %ptr, i32 4); If this is valid it means that a certain amount of type information is lost at the LLVM IL level and if it is not valid, then it is

On 2008-07-07, at 05:40, Benedict Gaster wrote: > %r1 = call i32 @llvm.atomic.load.add.p0i32( i32 addrspace(0)* > %ptr0, i32 4) > %r2 = call i32 @llvm.atomic.load.add.p11i32( i32 addrspace(11)* > %ptr11, i32 4) > call void @llvm.memory.barrier(i1 true, i1 true, i1 false, i1 false, > i32 11, i1 false) ; force read-modify-write %ptr11 to complete > > A problem with

On Thu, 3 Jul 2008, Benedict Gaster wrote: > I am slightly unclear about the semantics of the addrspace attribute and > there use with intrinsics. For example, is the following code valid: > > % ptr = malloc i32 addrspace(11) > % result = call i32 @llvm.atomic.load.add.i32( i32 addrspace(11)* %ptr, > i32 4); > > If this is valid it means that a certain amount of type

Thanks, I can now see that this can be implemented with Verifier.cpp. Even with this ability It is unclear that defining llvm.memory.barrier with an explicit address space argument is preferred over the llvm.memory.fence definition where the addrspace is encoded as part of the type as will be the case with the other atomic operations. What do you think? Ben On 7 Jul 2008, at 13:43,

Since we are using gnulib already, make use of xstrtol to parse the integer arguments to avoid extra suffixes, etc. Fixes commit 0f7bf8f714898c606e5d5015fff5b7803dcd1aee. --- mllib/getopt-c.c | 34 ++++++++++++++++++++++++---------- 1 file changed, 24 insertions(+), 10 deletions(-) diff --git a/mllib/getopt-c.c b/mllib/getopt-c.c index 1f129a7..2d3f9b6 100644 --- a/mllib/getopt-c.c +++

Hi everyone, I was just trying to catch some exceptions in my app, for "Record Not Found" I used this in my application.rb file rescue_from ActiveRecord::RecordNotFound, :with => :record_not_found rescue_from ActionController::NoMethodError, :with => :show_error private def record_not_found render :text => "404 Not Found", :status =>

I’ve been developing an optimization pass that uses the address space attribute (__attribute__((address_space(200))) to indicate different kinds of pointers to be treated differently (I’m making them be pointers to a “global” address space as in UPC). However, I’ve hit a snag in the frontend code generator: if I try to make a method call on a pointer with a custom address space, the frontend

How do I access the address qualifier from the store instruction. Given the following code: define void @test_unary_op_anegate(float %x, float addrspace(11)* %result) nounwind { entry: %neg = sub float -0.000000e+000, %x ; <float> [#uses=1] store float %neg, float addrspace(11)* %result ret void } When I attempt to generate this code, I'm

Hi, I got pulled off doing other things last week but I plan to get the support for address spaces to the intrinsics this week. As Benedict noted, the problem is that we don't carry the address space information with the intrinsics. Today, we will do an implicit cast to the default address space. My change will prevent that from happening by allowing the intrinsic to have a

The address qualifier is stored in the type of %result. From that operand, you can get the Value and then call getType. The type for result should be a PointerType which you cast to a PointerType and get the getAddressSpace e.g. cast<PointerType>(Ty)->getAddressSpace() -- Mon Ping On Sep 17, 2008, at 1:06 PM, Villmow, Micah wrote: > How do I access the address qualifier

Mon Ping, Thanks for the tip, but I can't for the life of me seem to get the Value from a StoreSDNode. From looking at the SelectionDAGNodes header file, the only class that has the getValue function call is SrcValueSDNode that returns a Value type. The only class that has getType is a ConstantPoolSDNode. I don't think that ConstantPoolSDNode is what I want and when I try to cast the

Hi, Great I look forward to the patch! One comment I had was on the name of the overloaded intrinsics. In your example you resolve the atomic.load.add to: @llvm.atomic.load.add.p0i32 // i32 ptr to default address space @llvm.atomic.load.add.p11i32 // i32 ptr to address space 11 and I was wondering could they instead be named: @llvm.atomic.load.add.p0.i32 // i32 ptr to default

I agree that if we intend that the it is always a complete barrier, but it is possible for a more general memory fence operation that has the ability to place a barrier on the region of memory that %ptr11 points to but in the case that it does not point to a valid address then it is assumed to be a complete barrier for that address space. As sum types are not directly support in LLVM,

Thank you for the prompt response, Matt. On Jan 20, 2014, at 3:03 PM, Matt Arsenault <Matthew.Arsenault at amd.com> wrote: > Since 3.4 you need to use the addrspacecast instruction to cast between address spaces. It's possible there are still some places left that haven't been fixed yet to use it instead of creating bit casts. Are you saying you think this is a bug and it should

Hi, Though I haven't looked into the implementation details, at the high level, I personally think having the address space argument is cleaner than having it encoded as a pointer. The memory barrier places a barrier on the entire address space. When I see the %ptr11 on the memory barrier instruction, my first instinct is to that it is a memory barrier on the region of memory that