search for: promoting

Hi All, Please consider the following case Test case -- -------------------------------------- char a; void fun () { return a; } -------------------------------------- Following disassembly (using llvm-dis) is generated for the above test case -------------------------------------- ; ModuleID = 'first.bc' @a = internal global i8 0 ; <i8*> [#uses=1] define i8 @fun(...) { entry:

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

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 =

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

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

...) and leave the imported copy local/unpromoted, the imported P==&foo comparison will fail (assume baz() is not referenced by or imported into b.cc). That is because P will point to the a.cc::foo() and the imported comparison will compare against the imported copy b.cc::foo(). This is avoided by promoting address taken static functions, in both their original module (if the function is in the global function index) and when it has been imported along with an address taken reference into another module. Similar logic applies to read-only static variables as mentioned in Section 4.1. The mechanics of...

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 it has a different size. -----Original Message----- From: Villmow, Micah

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 x [i8|i16]> v4i8 itself is a legal type, just not

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

Salut Ivan, On Fri, Jun 1, 2012 at 7:22 AM, Ivan Llopard <ivanllopard at gmail.com> wrote: > Hi Sebastian, > > Le 25/05/2012 18:54, Sebastian Pop a écrit : >> On Thu, May 24, 2012 at 5:40 PM, Sebastian Pop<spop at codeaurora.org>  wrote: >>> On Thu, May 24, 2012 at 5:06 PM, Hal Finkel<hfinkel at anl.gov>  wrote: >>>> Sebastian,

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

...rted > copy local/unpromoted, the imported P==&foo comparison will fail (assume > baz() is not referenced by or imported into b.cc). That is because P will > point to the a.cc::foo() and the imported comparison will compare against > the imported copy b.cc::foo(). This is avoided by promoting address taken > static functions, in both their original module (if the function is in the > global function index) and when it has been imported along with an address > taken reference into another module. Similar logic applies to read-only > static variables as mentioned in Section 4....

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