search for: promoted

...s langauge independent). This is what happens when we use char in calculations. Clang promotes char in calculations to int and this promotion is visible in the disassembly. However return node operand promotion is not visible in disassembly but LLVM is doing that. 2) Also should the char not be promoted to target integer (Target integer may be 16 bits). LLVM tries to promote to i32 (promotion to i32 is hardcoded in file SelectionDAGISel.cpp - function visitRet). The comment in LLVM code says "C calling convention requires the return type to be promoted to atleast 32 bits. But this is not...

...ssembly. However return node operand promotion is not > visible > in disassembly but LLVM is doing that. I think all currently defined calling conventions are "C like". You can add a calling convention and check for it in visitRet. > > > 2) Also should the char not be promoted to target integer (Target > integer may be 16 bits). LLVM tries to promote to i32 (promotion to > i32 > is hardcoded in file SelectionDAGISel.cpp - function visitRet). > > The comment in LLVM code says "C calling convention requires > the return type to be promoted to atl...

...pleValueType>::const_iterator PTTI = PromoteToType.find(std::make_pair(Op, VT.getSimpleVT().SimpleTy)); if (PTTI != PromoteToType.end()) return PTTI->second; assert((VT.isInteger() || VT.isFloatingPoint()) && "Cannot autopromote this type, add it with AddPromotedToType."); EVT NVT = VT; do { NVT = (MVT::SimpleValueType)(NVT.getSimpleVT().SimpleTy+1); assert(NVT.isInteger() == VT.isInteger() && NVT != MVT::isVoid && "Didn't find type to promote to!"); } while (!isTypeLegal(NVT) ||...

...urn value promotion will be removed from llvm backend and > implemented in both front-ends (clang and llvm-gcc) > > 2) The promotions are only applied to the return value in the body > of the function. > Return value of function definition and declaration will not be > promoted > > Example for a Target with 32-bit int type: > > char foo() { > char c = ... > return c; > } > > Is translated to: > > define i8 @foo() { > ... > %tmp = sext i8 ... to i32 > ret i32 %tmp > } Close. T...

...0x1500770, 0x1500b50 0x1500f60: i1 = select 0x1500bb0, 0x1500e90, 0x1500c80 0x15011b0: i1 = Constant <1> 0x1501220: i1 = xor 0x1500f60, 0x15011b0 0x15012d0: ch = BasicBlock <bb20 0x14ff930> 0x15013e0: ch = brcond 0x1501330, 0x1501220, 0x15012d0 The setcc's are promoted to i32, since they are comparing i32 operands. The problem arises when the select (0x1500f60) is promoted by SelectionDAGLegalize::PromoteOp(), because the select's i1 is promoted to i8, which triggers an assert because select's arguments (i32) don't match the new, promoted value ty...

...<4 x i64> is split to <2 x i64> > 2. Widen - this methods adds additional vector elements, but keeps the > element type. For example <3 x float> is legalized to <4 x float> > 3. Promote - this method widens each element in the vector. For example > SSE masks are promoted from <4 x i1> to <4 x i32> > 4. Scalarize - this method coverts vectors with a single element into a > scalar. For example, <1 x i64> into i64. > > >> The function getTypeToPromoteTo will return a <2 x i32> for a <2 x > i8>, <2 x i16> or &lt...

Vector promotion which is new in LLVM 3.1 is broken for sub32 bit types. The problem is in the VectorLegalizer::PromoteVectorOp. The function getTypeToPromoteTo will return a <2 x i32> for a <2 x i8>, <2 x i16> or <4 x i8>. The problem is that there are no vectors of size 1 defined for i32 or i16. The attached patch fixes these issues. This can be reproduced by setting in

...TI = > PromoteToType.find(std::make_pair(Op, > VT.getSimpleVT().SimpleTy)); > if (PTTI != PromoteToType.end()) return PTTI->second; > > assert((VT.isInteger() || VT.isFloatingPoint()) && > "Cannot autopromote this type, add it with > AddPromotedToType."); > > EVT NVT = VT; > do { > NVT = (MVT::SimpleValueType)(NVT.getSimpleVT().SimpleTy+1); > assert(NVT.isInteger() == VT.isInteger() && NVT != MVT::isVoid && > "Didn't find type to promote to!"); >...

...ecial handling during importing as described below. The local linkage types InternalLinkage and PrivateLinkage (private is the same as internal but is omitted from the symbol table) are handled the same for ThinLTO. 4.1 Static Variables Read-write or address taken static variables must always be promoted to global scope (i.e. non-discardable, non-local linkage) if they are imported to another module. This is important to ensure that one single copy of the static variable is used in address comparisons or when updating its value. The mechanics of static promotion are described below in Section 4.3....

...pleValueType>::const_iterator PTTI = PromoteToType.find(std::make_pair(Op, VT.getSimpleVT().SimpleTy)); if (PTTI != PromoteToType.end()) return PTTI->second; assert((VT.isInteger() || VT.isFloatingPoint()) && "Cannot autopromote this type, add it with AddPromotedToType."); EVT NVT = VT; do { NVT = (MVT::SimpleValueType)(NVT.getSimpleVT().SimpleTy+1); assert(NVT.isInteger() == VT.isInteger() && NVT != MVT::isVoid && "Didn't find type to promote to!"); } while (!isTypeLegal(NVT) ||...

...I = > PromoteToType.find(std::make_pair(Op, > VT.getSimpleVT().SimpleTy)); > if (PTTI != PromoteToType.end()) return PTTI->second; > > assert((VT.isInteger() || VT.isFloatingPoint()) && > "Cannot autopromote this type, add it with > AddPromotedToType."); > > EVT NVT = VT; > do { > NVT = (MVT::SimpleValueType)(NVT.getSimpleVT().SimpleTy+1); > assert(NVT.isInteger() == VT.isInteger() && NVT != MVT::isVoid && > "Didn't find type to promote to!"); >...

I don't know how your target architecture looks like, but I suspect that <4 x i8> should not be legalized to <1 x i32>. I think that what you are seeing is that <4 x i8> is first split into <2 x i8>, and later promoted to <2 x i32>. At the moment different targets can only affect type-legalization by declaring different legal types. A number of us discussed the possibility of allowing different targets to override the decisions for different types. But at the moment this is only a plan. -----Original Mes...

No, that is correct. I am adding the new types so that I can bitcast v2i8 into a v1i16 and then perform the 'and' operation and have legalize types turn the v1i16 into a scalar. Though I am having trouble in understanding how x86 supports the <1 x i64> type. Based on looking at the code, it should fail because v1i64 is not supported on the x86 platform as far as I can tell. Micah

...lvm backend and >>> implemented in both front-ends (clang and llvm-gcc) >>> >>> 2) The promotions are only applied to the return value in the body >>> of the function. >>> Return value of function definition and declaration will not be >>> promoted > > You might want to look at bug http://llvm.org/bugs/show_bug.cgi?id=3779. > > If I understand what you are proposing, it is exactly the opposite of > what gcc does, which would be annoying for someone trying to link gcc > and llvm compiled code. That's right. In gcc we...

...o the situation is slightly >> different than on Hexagon, where there are no general purpose registers >> of the same size as the predicate registers: i8. >> >> So on PPC it is "safe" to promote from i1 to i32 and to "allow confusion" >> between the promoted i32 and the existing operations that were using i32: >> as we can always select between a CR and a GPR following the op type. >> >> On Hexagon, if type legalization promotes i1 into i8, that would create >> this confusion between the i8 ops existing before legalization and t...

Ahh yep, thanks for catching that, new patch attached. > -----Original Message----- > From: Hal Finkel [mailto:hfinkel at anl.gov] > Sent: Tuesday, July 31, 2012 1:40 PM > To: Villmow, Micah > Cc: Developers Mailing List > Subject: Re: [LLVMdev] Vector promotion broken for <2 x [i8|i16]> > > Micah, > > I think that your patch is missing the necessary

Chris, Regardless of the optimization problem that we had discussions before, I think we all agreed that promotion of return value should take place in the front-end... Now I have a suggestion: In the message below you laid out the suggested IR for "char foo()" when its return value is promoted to i32 in front-end. You have applied the promotion both at the definition of function and its return statement. This leaves no way for backend to differentiate "char foo()" from "int foo()". Currently in llvm, promotion affects only the return value but function definition i...

In this thread I'm trying to merge two email threads into one, because both discuss the same problem that's troubling us and I would like to reach a conclusion on what would be the best approach. To minimize the size of this thread I only mention the subject of the other two threads: (1) [LLVMdev] Integer promotion of return node operand (initiated by Sachin) (2) [LLVMdev] trouble

...ow. The local linkage types > InternalLinkage and PrivateLinkage (private is the same as internal but is > omitted from the symbol table) are handled the same for ThinLTO. > > > > 4.1 Static Variables > > > > Read-write or address taken static variables must always be promoted to > global scope (i.e. non-discardable, non-local linkage) if they are imported > to another module. This is important to ensure that one single copy of the > static variable is used in address comparisons or when updating its value. > > > > The mechanics of static promotion a...

...vs i32) Regardless, I agree with you and shap that promotions should take place in the FrontEnd and this is my reason: The standard allows calling a function without prototype and assumes "int" return value; and I realize that this is the primary reason why the return value is being promoted. This ties this promotion to int type and not the size of any register in target, which in turn makes it a language issue rather than code generation issue; hence FrontEnd must take care of it. Now for our port, things are different. In most (sane) ports, the target provides an integer class fo...