search for: promote

...------------------------------ ; ModuleID = 'first.bc' @a = internal global i8 0 ; <i8*> [#uses=1] define i8 @fun(...) { entry: %tmp = load i8* @a ; <i8> [#uses=1] ret i8 %tmp } -------------------------------------- When LLVM constructs the DAG for above case - it tries to promote (during DAG construction phase - before any combine or legalize phase) the return node operand to i32. I have few doubts here: 1) If C language requires integer promotion of return value argument then should it not be done by the C language frontend. (I think LLVM is langauge independent). This...

On May 12, 2008, at 8:21 AM, Sachin.Punyani at microchip.com wrote: > > When LLVM constructs the DAG for above case - it tries to promote > (during DAG construction phase - before any combine or legalize phase) > the return node operand to i32. > > I have few doubts here: > 1) If C language requires integer promotion of return value argument > then should it not be done by the C language frontend. (I think LLVM &g...

Hrmm.... PromoteVectorOp doesn't seem to follow this at all. http://llvm.org/svn/llvm-project/llvm/trunk/lib/CodeGen/SelectionDAG/LegalizeVectorOps.cpp SDValue VectorLegalizer::PromoteVectorOp(SDValue Op) { // Vector "promotion" is basically just bitcasting and doing the operation // in a differen...

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

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

...g ways: > 1. Split - this splits vectors into two halves. For example on SSE4, > <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 getTypeTo...

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 any target: setOper...

v4i8 itself is a legal type, just not on the 'AND' operation. So there seems to be multiple problems here. 1) PromoteVectorOp doesn't handle the case where the types are not the same size, this occurs because #2 2) getTypeToPromoteTo doesn't actual check to see if the type it should promote to makes any sense. 3) PromoteVectorOp also doesn't handle the case where getTypeToPromoteTo returns an invalid t...

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

Notice that PromoteVectorOp is called after the type legalization legalized all of the types in the program. It legalizes the *operations*, not the types. So, you should only see legal types (Legal types are types that fit into your registers). So, if your target has v2i32, I suspect that v4i8 is an illegal because...

If v4i8 is a legal type then getTypeToPromoteTo should return the pair v4i8 and 'legal'. This looks like the root of the problem. -----Original Message----- From: Villmow, Micah [mailto:Micah.Villmow at amd.com] Sent: Monday, July 30, 2012 22:10 To: Rotem, Nadav; Developers Mailing List Subject: RE: Vector promotion broken for <2...

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

...ev-bounces at cs.uiuc.edu] On Behalf Of Villmow, Micah Sent: Saturday, July 28, 2012 01:54 To: Developers Mailing List Subject: [LLVMdev] Vector promotion broken for <2 x [i8|i16]> 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 any target: setOper...

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

...RC as i32, and that PPC >> also has general purpose i32 registers GPRC, so 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 crea...

...() and EVT::getTypeForEVT. > > -Hal > > On Fri, 27 Jul 2012 22:54:24 +0000 > "Villmow, Micah" <Micah.Villmow at amd.com> wrote: > > > 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 ca...

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

...value (initiated by myself) To summarize: Evan has replied to thread (1) and suggested to add a calling convention and check for it in visitRet Dan replied to thread (2) and suggested to add a new field to the TargetLowering class, and then let each target specify the minimum integer type to promote return types to Either way, I think we all agree that the root of the problem is the FIXME in SelectionDAGLowering::visitRet() But what is the preferred method? Thanks Ali -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/piperma...

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

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