similar to: [LLVMdev] Making GEP into vector illegal?

On Oct 14, 2008, at 9:50 AM, Mon Ping Wang wrote: > Hi, > > I ran into a case where ScalarReplAggregates can not promote an array > of vectors into registers, e..g, > %a = alloca [8 x <2 x float>], align 8 > %arrayidx74597 = getelementptr [8 x <2 x float>]* %a, i32 0, > i32 1, i32 0 ; <float*> [#uses=2] > %tmp76 = load float* %arrayidx74597,

Hi, I didn't know that about bitcast. This becomes important if someone wants a pointer to a vector element as we would either need to support the bistcast or we just don't allow that. For most vector code that I'm aware of, no one really wants to take an address of vector element as by doing so, one is kind of scalarizing the vector which would be bad for performance. If

On Oct 14, 2008, at 11:02 AM, Duncan Sands wrote: > Hi Mon Ping, > >> I would like to make it illegal to GEP into a vector as I think it is >> cleaner and more consistent. Opinions? Comments? > > now that arrays are first class types, I think vectors should become > a subclass of ArrayType. This would get rid of a lot of duplicated > code, and also fix a bunch of

Hi Chris, > I'm happy about factoring the code better, but a vectortype isn't an > arraytype (isa<ArrayType>(V) should be false). Maybe a common base > class (like sequential type) would be better? currently anything you can do with an array you can do with a vector. So from this functional viewpoint it would make sense to have a vector be an array with more stuff

Hi Mon Ping, > I would like to make it illegal to GEP into a vector as I think it is > cleaner and more consistent. Opinions? Comments? now that arrays are first class types, I think vectors should become a subclass of ArrayType. This would get rid of a lot of duplicated code, and also fix a bunch of problems with vectors (eg: that sizes are wrong; currently we think that a <n x

Hi, Something like a sequential type makes sense especially in light of what Duncan is point out. I agree with Chris that a vector shouldn't be treated as a short array. Vectors have different alignment rules and operations. It make senses to talk about doing operations on vectors like add or speak of having a mask for a vector. I don't feel like that it make sense to talk of

On Sep 13, 2008, at 1:07 PM, Matthijs Kooijman wrote: > Hi Dan, > >> Changing PromoteCastOfAllocation to not replace aggregate allocas >> with >> non-aggregate allocas if they have GEP users sounds reasonable to me. > This sounds reasonable indeed, but still a bit arbitrary. Haven't > figured out > anything better yet, though. > >> Finding the

Hi Dan, > Changing PromoteCastOfAllocation to not replace aggregate allocas with > non-aggregate allocas if they have GEP users sounds reasonable to me. This sounds reasonable indeed, but still a bit arbitrary. Haven't figured out anything better yet, though. > Finding the maximum alignment is sometimes still useful though, so > it would be nice to update the alignment field of

In Joe programmer language (i.e. C ;) ), are we basically talking about disallowing: float4 a; float* ptr_z = &a.z; ? Won't programmers just resort to: float4 a; float* ptr_z = (float*)(&a) + 3; ? On Oct 14, 2008, at 3:55 PM, Mon Ping Wang wrote: > Hi, > > Something like a sequential type makes sense especially in light of > what Duncan is point out. I agree

Hi Duncan, I can see your point that arrays are similar except for the alignment restrictions when representing them in memory. However, the two constructs serves different purpose for me. I don't think of a vector isA array. A vector is a construct that supports a form of parallelism. It is a container that allow people to expression some element wise parallelism in a

Hi, when I updated the sources today there were several small problems that stopped the windows version from compiling, here are the patches m. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: win32patches.txt URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20041115/34634455/attachment.txt>

Just for reference, my C example was for my own clarification. I dived into LLVM having to write a TargetMachine and I've been keeping busy without having to learn much IR (yet). I was really trying to use C as a pseudo-IR. I get that the idea is allowing IR to directly express the address of part of a vector complicates (prevents?) certain optimizations. However, due to my own

On Oct 14, 2008, at 11:43 PM, Mike Stump wrote: > That statement was that: > >> float4 a; >> float* ptr_z = (float*)(&a) + 3; > > ``violates strict aliasing`` > > That assertion is wrong. The docs says: > > @item may_alias > Accesses to objects with types with this attribute are not subjected > to > type-based alias analysis, but are instead

John, I have looked at the SAFECode and thought following sould work if (isa<Constant>(I.getOperand(0))) { Out << "*** operand 0 is a constant ******"; if (Instruction *operandI = dyn_cast<Instruction>(I.getOperand(0))) { Out << "********operand is an instruction ****"; if (GetElementPtrInst *gepI =

On Tue, Oct 14, 2008 at 1:34 PM, Daniel M Gessel <gessel at apple.com> wrote: > In Joe programmer language (i.e. C ;) ), are we basically talking > about disallowing: > > float4 a; > float* ptr_z = &a.z; > > ? That's my reading as well; the argument for not allowing it is just to make optimization easier. We don't allow addressing individual bits either,

On 1/21/2011 10:46 PM, Surinder wrote: > John, > > I have looked at the SAFECode and thought following sould work > > if (isa<Constant>(I.getOperand(0))) > { Out<< "*** operand 0 is a constant ******"; > if (Instruction *operandI = dyn_cast<Instruction>(I.getOperand(0))) > { Out<<

John, I have looked at the real code (instead of the obsolete one) and it appears to be easy to find if an operand is a getelementptr instruction. if (ConstantExpr * CE = dyn_cast<ConstantExpr>(I.getOperand(0))) { Out<< "*** operand 0 is a constant Expr******"; if (CE->getOpcode() == Instruction::GetElementPtr) { Out<< "*** operand 0 is

On Oct 14, 2008, at 5:41 PM, Chris Lattner wrote: > On Oct 14, 2008, at 4:30 PM, Mike Stump wrote: >> On Oct 14, 2008, at 1:54 PM, Eli Friedman wrote: >>> Maybe... although note that with gcc vector intrinsics, this >>> violates >>> strict aliasing. gcc does allow you to use a slightly more >>> elaborate >>> workaround with a union,

I got a little problems with strings (const char pointers). Global variables holding the string literal are declared correctly, but i have a problem when I pass this string to a function: it asserts with this message. Assertion failed: ((i >= FTy->getNumParams() || FTy->getParamType(i) == Args[i]->getType()) && "Calling a function with a bad signature!"), function

Hi all, I am new to LLVM, and I am learning how to use LLVM for profiling. I need to pass an array to an external method, and insert a call instruction to the method in the code. After reading a few source files, I've tried using GetElementPtrInst to pass an array, but it fails at llvm::GetElementPtrInst::hasAllZeroIndices() const + 0 std::vector<Value*> Args(1);