search for: signext

Hello, For a simple function taking a short and returning a short, clang generates IR with this function signature: define signext i16 @foo(i16 signext %x) Some questions please: 1) For the input parameter and return value, does the target control whether clang uses signext vs something else? If so, how does this target query work? 2) Does the presence of the signext mean it's imperative to sign extend, or that extensi...

...n definition information. > So: > > signed char g(...); > void foo(){ > x = g(...); > } > > Would translate to: > > define void @foo(){ > Entry: > %call = call i32 @g(...) > ... > } > declare signed i8 @g(...) Ok. We already have this, with the 'signext' attribute. This code: signed char g(); signed char foo(){ return g(); } compiles into: define i8 @foo() signext nounwind { entry: %tmp1 = tail call i8 (...)* @g( ) signext nounwind ; <i8> [#uses=1] ret i8 %tmp1 } declare i8 @g(...) signext Note that the 'signext' attr...

...ved in Function class. > > Sure. Adding an attribute is what we need to do. To handle the > indirect call case, llvm puts attributes both on the function > definitions and on the calls to those functions. That makes a lot of sense > > Ok. We already have this, with the 'signext' attribute. This code: > > signed char g(); > signed char foo(){ > return g(); > } > > compiles into: > > define i8 @foo() signext nounwind { > entry: > %tmp1 = tail call i8 (...)* @g( ) signext nounwind ; <i8> > [#uses=1] > ret i8 %tmp1 >...

> -----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 signature: > > define signext i16 @foo(i16 signext %x) > > Some questions please: > > 1) For the input parameter and r...

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 using LLVM 2.1 in ca...

...s, 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 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? >...

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 way in LLVM to modify the > parameter's type? This is an ABI requir...

...39;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 "i32". This means that the high bits of the argument will be indeterminate instead of sign-extension. In practice, PowerPC64, SPARC64, MIPS64 tend to get zero- or sign-extended data anyway (since all oper...

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

...tore i32 11, i32* %f, align 4 %1 = load i32, i32* %b, align 4 %2 = load i32, i32* %c, align 4 %3 = load i32, i32* %d, align 4 %4 = load i32, i32* %e, align 4 %5 = load i32, i32* %f, align 4 %arraydecay = getelementptr inbounds [3 x i32], [3 x i32]* %a, i32 0, i32 0 call void @test(i32 signext %1, i32 signext %2, i32 signext %3, i32 signext %4, i32 signext %5, i32* %arraydecay) ret i32 0;} I want to known how to compile local array a to a local variable Thank you -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm...

...%1 = load i32, i32* %b, align 4 > %2 = load i32, i32* %c, align 4 > %3 = load i32, i32* %d, align 4 > %4 = load i32, i32* %e, align 4 > %5 = load i32, i32* %f, align 4 > %arraydecay = getelementptr inbounds [3 x i32], [3 x i32]* %a, i32 0, i32 0 > call void @test(i32 signext %1, i32 signext %2, i32 signext %3, i32 signext %4, i32 signext %5, i32* %arraydecay) > ret i32 0;} > I want to known how to compile local array a to a local variable Your question is not totally clear: a *is* a “local variable” on the stack, this is the line: > %a = alloca [3 x i3...

...t 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 != ISD::ANY_EXTEND && VT.isInteger()) { > EVT MinVT = TLI.getRegisterType(*DAG.getContext(), MVT::i32); > if (VT.bitsLT(MinVT)) > VT = MinVT; > } > > There have been a few discussions ab...

...t(), 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 != ISD::ANY_EXTEND && VT.isInteger()) { EVT MinVT = TLI.getRegisterType(*DAG.getContext(), MVT::i32); if (VT.bitsLT(MinVT)) VT = MinVT; } There have been a few discussions about this snippet on llvmdev in...

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 ABIInfo base class? They also are not marked virtual yet targets are expected override as needed.

...or: expected string not found in input // CHECK: define i{{.*}} @main({{.*}}) #0 ^ <stdin>:1:1: note: scanning from here ; ModuleID = '/home/seurer/llvm/llvm-test/tools/clang/test/CodeGenCXX/main-norecurse.cpp' ^ <stdin>:6:1: note: possible intended match here define signext i32 @main(i32 signext %argc, i8** %argv) #0 { ^ -- -Bill Seurer

Hi, All. Does anybody know about ConstantExpr in llvm? What's it? Since it always appears after llvm optimization such as -O2 level, what is it supposed to be to codegen? I am wondering it represents constant value which can be determined or computed at compile-time(actually is link-time) to improve performance. Although we do not know the actual constant value util the object file is linked.

...er 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 it can promote only if > needed. I don't understand what the point of this is. Surely this can all be handled by the calling convention and the signext/zeroext attributes? For example, suppose a function returns a short, but on the target that means being returned in an i32, with sign extension. Then in the IR the function is defined as returning an i16 with the signext attribute: define signext i16 @f(... The target calling convention specif...

On May 28, 2008, at 11:53 AM, <Alireza.Moshtaghi at microchip.com> <Alireza.Moshtaghi at microchip.com > wrote: >> Ok. We already have this, with the 'signext' attribute. This code: >> >> signed char g(); >> signed char foo(){ >> return g(); >> } >> >> compiles into: >> >> define i8 @foo() signext nounwind { >> entry: >> %tmp1 = tail call i8 (...)* @g( ) signext nounwind > ; &lt...

Hi Rafael, if the nasty hack I mentioned in the PR was removed then the following code should work for both X86 and ARM: define signext i16 @f() nounwind { entry: %0 = tail call signext i16 @h() nounwind %1 = sext i16 %0 to i32 tail call void @g(i32 %1) nounwind %2 = load i16* @x, align 2 ret i16 %2 } This is what llvm-gcc currently produces. On x86 the value would be returned in an i16 re...

On Mar 16, 2011, at 9:31 AM, Cameron Zwarich wrote: > Promoting the return value is unsafe for bool returns on x86-64, which in the latest revision of the ABI only guarantees that the top 7 bits of the 8-bit register are 0. My comment is a bit off, because the question of what type to make the return value is somewhat orthogonal to the question of which zext assert we should add. Cameron