search for: promotion

...8> [#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 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 pr...

...achin.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 > is > 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 disas...

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 different type. For example, x86 promotes ISD::AND on v2i32 to // v1i64. EVT VT = Op.getValueType(); assert(Op.getNode()->getNumValues() == 1 && "Can't promote a vector with multiple results!&qu...

...e implementation. 1) Is there any last change that we would like to add? 2) Has anyone been working on it? I haven't seen any thing new in the code so I assume the answer is no... Thanks Alireza Moshtaghi Senior Software Engineer Development Systems, Microchip Technology Subject: Troubling promotion of return value to Integer ... On May 29, 2008, at 10:30 AM, <Alireza.Moshtaghi at ...> <Alireza.Moshtaghi at ... > wrote: > Let me summarize what we discussed so far: > > 1) The return value promotion will be removed from llvm backend and > implemented in both fron...

...8 comparison should be generated. Another nice feature in the CellSPU architecture is the selb instruction that directly corresponds to SELECT. Again, though, if SETCC is i32, then SELECT has to be i32; if SETCC is i16, then SELECT has to be i16, etc. Currently, I've got what looks to be a promotion problem showing up when compiling _addvsi3.c during the libgcc2 phase of llvm-gcc. The optimized selection DAG is show below: Optimized lowered selection DAG: SelectionDAG has 20 nodes: 0x14ffca0: ch = EntryToken 0x14ffca0: <multiple use> 0x1500710: i32 = Register #1025 0x1500...

...ing is that it is returning a <2 x i32> because <1 x i32> does not exist. Micah > -----Original Message----- > From: Rotem, Nadav [mailto:nadav.rotem at intel.com] > Sent: Monday, July 30, 2012 10:51 AM > To: Villmow, Micah; Developers Mailing List > Subject: RE: Vector promotion broken for <2 x [i8|i16]> > > > >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. > > The Type-Legali...

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

...Op also doesn't handle the case where getTypeToPromoteTo returns an invalid type. Micah > -----Original Message----- > From: Rotem, Nadav [mailto:nadav.rotem at intel.com] > Sent: Monday, July 30, 2012 12:06 PM > To: Villmow, Micah; Developers Mailing List > Subject: RE: Vector promotion broken for <2 x [i8|i16]> > > > 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 r...

...2.2 Linkage Effects 2.2.2 ExternalLinkage 2.2.1 WeakAnyLinkage 2.2.2 WeakODRLinkage 2.2.3 AppendingLinkage 2.2.4 CommonLinkage 3 Linkonce Values 3.1 Linkage Effects 3.2 Importing Strategy 4 Static Values 4.1 Static Variables 4.2 Static Functions 4.3 Static Promotion 4.3.1 Linkage Effects 4.3.2 Renaming 5 Linkage Change Summary Table 1 Introduction This document describes handling of symbols that may need linkage type changes or renaming to support ThinLTO importing.This applies to both the symbol in its original module as well as in the module im...

...o your registers). So, if your target has v2i32, I suspect that v4i8 is an illegal because it has a different size. -----Original Message----- From: Villmow, Micah [mailto:Micah.Villmow at amd.com] Sent: Monday, July 30, 2012 21:26 To: Rotem, Nadav; Developers Mailing List Subject: RE: Vector promotion broken for <2 x [i8|i16]> 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 bit...

...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 x [i8|i16]> 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...

...ty of allowing different targets to override the decisions for different types. But at the moment this is only a plan. -----Original Message----- From: Villmow, Micah [mailto:Micah.Villmow at amd.com] Sent: Monday, July 30, 2012 21:05 To: Rotem, Nadav; Developers Mailing List Subject: RE: Vector promotion broken for <2 x [i8|i16]> Sorry, <4 x i8> should convert to a <1 x i32>. What currently is happening is that it is returning a <2 x i32> because <1 x i32> does not exist. Micah > -----Original Message----- > From: Rotem, Nadav [mailto:nadav.rotem at intel.com]...

...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 From: Rotem, Nadav [mailto:nadav.rotem at intel.com] Sent: Saturday, July 28, 2012 12:56 PM To: Villmow, Micah; Developers Mailing List Subject: RE: Vector promotion broken for <2 x [i8|i16]> I think that you attached the wrong patch. The attached patch is the one which adds the new MVT types. From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Villmow, Micah Sent: Saturday, July 28, 2012 01:54 To: Developers Mail...

Rafael Espindola wrote: >>> 1) The return 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 wi...

...romoted ones.  Then as Ivan was suggesting, we will have to >> provide custom expansion to promote the "illegal" ops on i8 on almost >> all the operations, except logical ops. > > I think there is also another (and cleaner) workaround, a kind of > operation-based type promotion of __illegal__ types. > This can be done by simply setting the operation with illegal type > result to have a custom expander, for example: > > setOperationAction(ISD::AND, MVT::i1, Custom) > I was exploring something similar using exactly this function. > See LowerOperationWrap...

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 modifications in > lib/VMCore/ValueTypes.cpp to EVT::getEVTString() and EVT::getTypeForEVT. > > -Hal > > On Fri, 27 Jul 2012 22:54:24 +0000 > "Villmow, Micah"...

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

...;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 with 32-bit promotion of return 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...

...ODRLinkage > > 2.2.3 AppendingLinkage > > 2.2.4 CommonLinkage > > 3 Linkonce Values > > 3.1 Linkage Effects > > 3.2 Importing Strategy > > 4 Static Values > > 4.1 Static Variables > > 4.2 Static Functions > > 4.3 Static Promotion > > 4.3.1 Linkage Effects > > 4.3.2 Renaming > > 5 Linkage Change Summary Table > > > > Thanks for the writeup! A few notes/questions below. Sorry > for the slow response. > > > 1 Introduction > > > > This document describes handlin...

Chris, I did not quite understand the "The bad thing about ..." part of your argument. I'm not sure which of the two scenarios are you comparing (promoting in FrontEnd vs BackEnd) or (promotion to int 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...