similar to: [LLVMdev] signext on function parameters and return.

> -----Original Message----- > From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] > On Behalf Of Steve King > Sent: 23 July 2015 01:45 > To: llvmdev at cs.uiuc.edu > Subject: [LLVMdev] signext on function parameters and return. > > Hello, > For a simple function taking a short and returning a short, clang > generates IR with this function

Hello Pedro, As others have said we're assuming that you're using Clang as the frontend, the MSP430TargetInfo class inside lib/Basic/Targets.cpp (clang codebase) set ints to be 16 bits wide, so you should get 16bit mults straight away without promotion. But anyways for 8bit multiplicantions you can do the following to bypass argument promotion: 1) go to the lib/CodeGen/TargetInfo.cpp

On Thu, Jul 23, 2015 at 3:59 AM, Daniel Sanders <Daniel.Sanders at imgtec.com> wrote: > > The target hook is classifyArgumentType() and classifyReturnType() in tools/clang/lib/CodeGen/TargetInfo.cpp and returning ABIArgInfo::getExtend() causes the signext/zeroexts to be emitted appropriately for the type. Thanks for the great help. Should these classify calls be moved down into the

Hello, I'm trying to change the default behavior for how structures are passed to functions to use pass-by-value. Currently LLVM's default behavior is to pass structures by reference. I'm not disputing the benefits of this but I really want to change the default behavior for experimentation purposes. To this end I've changed the code in DefaultABIInfo::classifyArgumentType() to

Hi, On Wed, Jun 13, 2012 at 9:55 AM, Martinez, Javier E < javier.e.martinez at intel.com> wrote: > Hello,**** > > ** ** > > I’m trying to change the default behavior for how structures are passed to > functions to use pass-by-value. Currently LLVM’s default behavior is to > pass structures by reference. I’m not disputing the benefits of this but I > really want to

So, I'm not really sure if this is the right approach. I'd like some folks from the LLVM side of things to chime in. In general, I'm not certain we want to continue growing our dependence on the signext and zeroext attributes on return types, or whether we want to do the extension in the frontend instead. Most of the targets in Clang currently eagerly zext or sext the return value to

In SelectionDAGBuilder::visitRet(), there is this bit of code: // FIXME: C calling convention requires the return type to be promoted // to at least 32-bit. But this is not necessary for non-C calling // conventions. The frontend should mark functions whose return values // require promoting with signext or zeroext attributes. if (ExtendKind !=

Hal Finkel <hfinkel at anl.gov> wrote on 16.03.2015 17:56:20: > If you want to do it at a clang level, the right thing to do is to > fixup the ABI lowerings for pointers to keep them pointers in this case. > So this is an artifact of the way that we pass structures, and > constructing a general solution at the ABI level might be tricky. > I've cc'd Uli, who did most

I'm trying to fix a longstanding bug with library function calls on platforms where int is passed sign-extended in a register (it badly affects SystemZ, and has a chance of affecting PowerPC64, SPARC64, MIPS64 as well). The problem is that, on these platforms, C int corresponds to a "i32 signext" parameter, but all LLVM passes inserting library calls currently use just

I have a c function that takes a char as a parameter. When it is compiled to bytecode, it gets translated to i8 signext. Why is signext getting added to the type? It doesn't get added if the parameter is an int. Is there a way to alter the parameter in the c code so that it simply gets translated to an i8, or is there a way in LLVM to modify the parameter's type? By the way, I am

Thanks for your response. When I attempt to get the parameter attribute lists for the function and its call sites, the list is NULL. Is there someone else I should be looking to get the parameter attributes? Chris Lattner wrote: > On Wed, 30 Apr 2008, Ryan M. Lefever wrote: >> I have a c function that takes a char as a parameter. When it is >> compiled to bytecode, it gets

On Wed, 30 Apr 2008, Ryan M. Lefever wrote: > I have a c function that takes a char as a parameter. When it is > compiled to bytecode, it gets translated to i8 signext. Why is signext > getting added to the type? It doesn't get added if the parameter is an > int. Is there a way to alter the parameter in the c code so that it > simply gets translated to an i8, or is there a

It appears that the only thing that has parameter attributes is the function type. However, you can't simply change a function's type without reconstructing the whole function, can you? Also, am I correct that it would not be safe to remove the parameter attribute's from a FunctionType? Ryan M. Lefever wrote: > Thanks for your response. When I attempt to get the parameter

On Mar 16, 2011, at 5:58 AM, Ken Dyck wrote: > In SelectionDAGBuilder::visitRet(), there is this bit of code: > > // FIXME: C calling convention requires the return type to be promoted > // to at least 32-bit. But this is not necessary for non-C calling > // conventions. The frontend should mark functions whose return values > // require promoting

Hi Chandler, That's embarrassing how weird this part of clang is. I have a provisional patch which fixes the problem but underlines clang's problems. I will submit it tonight for comments. суббота, 18 октября 2014 г. пользователь Chandler Carruth написал: > > On Fri, Oct 17, 2014 at 7:51 AM, Anton Korobeynikov < > anton at korobeynikov.info >

Hi, > What we are trying to do is to add new attributes (more maybe added > later): > > > sign_ext_from_i8, sign_ext_from_i16 > > zero_ext_from_i8, zero_ext_from_i16 > > to function definition so (assuming that both caller and callee are > generated in the same front-end) the caller will know if the callee has > already extended the return value or not, then

Hi Duncan, thanks for the hint. I tried both variants: define <4 x float> @masked_add_1(<4 x i1> signext %mask, <4 x float> %a, <4 x float> %b) define <4 x float> @masked_add_32(<4 x i32> %mask, <4 x float> %a, <4 x float> %b) Unfortunately, this will raise an assertion: Wrong types for attribute: zeroext signext noalias nocapture sret byval nest

On 2/16/2016 8:44 AM, Konstantin Vladimirov via llvm-dev wrote: > > CI->getArgOperand(0) returns operand with type (double*) rather then > double, because in our ABI doubles are passed via memory. The LLVM intrinsics in the LLVM IR must conform to whatever the IR's requirements are. That means that even in the case of your backend, the arguments to the intrinsic must be doubles,

Hi, Working on private backend, based on llvm-3.7 Inside lib/Transforms/InstCombine/InstCombineCompares.cpp there is attempt to optimize fabs: if (F->getIntrinsicID() == Intrinsic::fabs || ... switch (I.getPredicate()) { ... case FCmpInst::FCMP_OGT: return new FCmpInst(FCmpInst::FCMP_ONE, CI->getArgOperand(0), RHSC); But CI->getArgOperand(0)

Hi, What are the intended semantics of noalias when applied to a vector of pointers? signext/zeroext parameter attributes are incorrectly rejected for vectors (bug 15391), and I'm not sure if the same is true for noalias when applied to pointer vectors. There's no mention of it in the langref, and the verifier currently rejects it. Is it supposed to work? Are pointers within the