search for: promotes

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

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

...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!"); EVT NVT = TLI.getTypeToPromoteTo(Op.getOpcode(), VT); DebugLoc dl = Op.getDebugLoc(); SmallVector&lt...

Below I have pasted the latest design that we discussed... Now we would like to pick it up and do the 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

After a hiatus on the CellSPU development, I've got all of the instructions necessary to get the llvm-gcc frontend to build. I've now discovered a new and interesting problem that I'm not sure how to solve cleanly and it's due to the fact that CellSPU has no fixed size condition flags. CellSPU's condition flags depend on the size of what's being compared, i.e., if both

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] > Sent: Monday, July 30, 2012 10:51 AM > To: Villmow, Micah; Developers Mailing List > Subject: RE: Vector promotion broken

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

...p://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!"); > EVT NVT = TLI.getTypeToPromoteTo(Op.getOpcode(), VT); > DebugLoc dl =...

As mentioned in the Updated ThinLTO RFC ( http://lists.cs.uiuc.edu/pipermail/llvmdev/2015-May/086211.html), I am sending the symbol linkage and renaming required by ThinLTO as a separate RFC. It is included below. I've also attached the doc in pdf form, since the formatting (especially for the table at the end) may not come through in the copied text below well. Thanks! Teresa ThinLTO

...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!"); EVT NVT = TLI.getTypeToPromoteTo(Op.getOpcode(), VT); DebugLoc dl = Op.getDebugLoc(); SmallVector&lt...

...://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!"); > EVT NVT = TLI.getTypeToPromoteTo(Op.getOpcode(), VT); > DebugLoc dl...

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

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

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 will not be >>> promoted

...PC 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 the >> newly promoted ones.  Then as Ivan was suggesting, we will have to >> provide custom expansion to promote the "illegal" ops on i8 on almost >> all the operati...

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

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

Thanks for the comments! Responses below. Teresa On Tue, Jul 21, 2015 at 1:06 PM, Duncan P. N. Exon Smith < dexonsmith at apple.com> wrote: > > > On 2015-Jul-14, at 13:33, Teresa Johnson <tejohnson at google.com> wrote: > > > > As mentioned in the Updated ThinLTO RFC ( > http://lists.cs.uiuc.edu/pipermail/llvmdev/2015-May/086211.html), I am > sending the

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