similar to: [LLVMdev] AddressSpace question

Every GlobalAddress has a GlobalValue, Every GlobalValue is a PointerType, Every PointerType has an AddressSpace. So is it ok to add a method getAddressSpace in GlobalAddressSDNode class itself? Currently we have to do GSDN->getGlobal()->getType()->getAddressSpace(). - Sanjiv

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

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

Hello all, I recently finished merging the last 3.5 months of upstream changes into our CHERI LLVM fork and would like to suggest something to both simplify our future merges and also avoid bugs for targets such as AVR that use non-zero pointer address spaces. We make extensive use of address spaces: all our pointers (CHERI capabilities) use address space 200 instead of the default zero to

On Thu, 13 Sep 2007 Alireza.Moshtaghi at microchip.com wrote: > I think it all boils down to whether you think it is time to incorporate > these extensions into LLVM IR and how long do you think it will take to > do so? Sure, any time is good. The reason we don't have this now is primarily because noone has stepped up to contribute it. If you're like to start this, I'd be

Thank you Chris and Christopher, I agree... the Embedded C Language Extensions report provides a good foundation to build on, and what it proposes as far as Address Space is probably a super set of what we have in our existing compiler (and probably would like to keep) so no conflict there. I also agree that regardless of how we would like to deal with pointers, the same extensions must be applied

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

For a datapoint, Julia uses the following function description to implement approximately the capability of those functions. We then also verify that there's no direct inttoptr/ptrtoint into our gc-tracked AddressSpace with a custom verifier pass (among other sanity checks). I can provide additional details and pointers to our gc-root tracking algorithm implementation if desired (I also plan

> -----Original Message----- > From: Peter Collingbourne [mailto:peter at pcc.me.uk] > Sent: 04 January 2011 21:42 > To: Anton Lokhmotov > Cc: cfe-dev at cs.uiuc.edu > Subject: Re: OpenCL support > > Here are my comments on the second patch. > > > +enum OpenCLAddressSpace { > > + OPENCL_PRIVATE = 0, > > + OPENCL_GLOBAL = 1, > > + OPENCL_LOCAL

Chris, Extending LLVM IR to support PointerTypes that take an address space is what I was hoping to avoid. However, if we want to do things right, that is probably the way to go. Now that we got here, let me write some of my thoughts on this and solicit your input: --- 1) Syntax extension: In our existing compiler for 8-bit microcontrollers, we have introduced rom and ram qualifiers (with ram

On Sep 12, 2007, at 6:41 PM, <Alireza.Moshtaghi at microchip.com> <Alireza.Moshtaghi at microchip.com> wrote: > Chris, > Extending LLVM IR to support PointerTypes that take an address > space is > what I was hoping to avoid. However, if we want to do things right, > that > is probably the way to go. Now that we got here, let me write some > of my >

> %temp = shufflevector <3 x i16> %incoming, <3 x i16> undef, <4 x i32> > <i32 0, i32 1, i32 2, i32 undef> > %out = bitcast <4 x i16> %temp to i64 I seem to have misread the destination type, you'd obviously want "<1 x i64>" instead of "i64" in everything I've written. Tim.

Here is the error that I get: Assertion failed: (i >= FTy->getNumParams() || FTy->getParamType(i) == Params[i]->getType()) && "Calling a function with a bad signature!" Yakov On Mon, Nov 14, 2011 at 9:05 PM, Eric Christopher <echristo at apple.com>wrote: > You'll probably need to dump both the source and the dest and show the > code that's being

yes - i checked that the src->getType()->isFloatTy() is true Yakov On Mon, Nov 14, 2011 at 8:24 PM, Duncan Sands <baldrick at free.fr> wrote: > On 14/11/11 19:20, Yakov Malinkovich wrote: > >> I sure that is. >> > > Did you test it? Can you do: src->getType()->isFloatTy() > > > What could be other reasons for such error? > > The only

So what do you think the problem is? Thank you. Yakov On Mon, Nov 14, 2011 at 10:20 PM, Duncan Sands <baldrick at free.fr> wrote: > On 14/11/11 21:11, Yakov Malinkovich wrote: > >> Here is the error that I get: >> Assertion failed: (i >= FTy->getNumParams() || FTy->getParamType(i) == >> Params[i]->getType()) && "Calling a function with a

On Fri, Feb 18, 2011 at 03:27:13PM -0000, Anton Lokhmotov wrote: > > -----Original Message----- > > From: Peter Collingbourne [mailto:peter at pcc.me.uk] > > Sent: 04 January 2011 21:42 > > To: Anton Lokhmotov > > Cc: cfe-dev at cs.uiuc.edu > > Subject: Re: OpenCL support > > > > Here are my comments on the second patch. > > > > >

On 14/11/11 21:11, Yakov Malinkovich wrote: > Here is the error that I get: > Assertion failed: (i >= FTy->getNumParams() || FTy->getParamType(i) == > Params[i]->getType()) && "Calling a function with a bad signature!" That's not being generated by the CreateCast, so it looks like your description of the problem was quite misleading. Ciao, Duncan. >

I have a function that should work only with vector types having element type as a power of 2. So if I get total 48 bit vector I should force it to be rounded to total 64 bit vector Yakov On Fri, May 4, 2012 at 10:37 PM, Tim Northover <t.p.northover at gmail.com> wrote: > > > %temp = shufflevector <3 x i16> %incoming, <3 x i16> undef, <4 x i32> > >

You'll probably need to dump both the source and the dest and show the code that's being generated. A lot of guessing here that's not getting us very far very fast. -eric On Nov 14, 2011, at 10:56 AM, Yakov Malinkovich wrote: > yes - i checked that the src->getType()->isFloatTy() is true > Yakov > > > On Mon, Nov 14, 2011 at 8:24 PM, Duncan Sands <baldrick

I sure that is.What could be other reasons for such error? Yakov On Mon, Nov 14, 2011 at 5:44 PM, Duncan Sands <baldrick at free.fr> wrote: > On 14/11/11 16:39, Yakov Malinkovich wrote: > >> It doesnt work it fails with assertation that cast is invalid .What >> could be done? >> > > Maybe src doesn't have Float type? > > Ciao, Duncan. > > >