search for: promot

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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