search for: abiarginfo

...check how other targets do it in the same file. The important part here is how you implement the classifyReturnType and classifyArgumentType functions, they should basically look like this: class MSP430ABIInfo : public ABIInfo { public: MSP430ABIInfo (CodeGenTypes &CGT) : ABIInfo(CGT) {} ABIArgInfo classifyReturnType(QualType RetTy) const; ABIArgInfo classifyArgumentType(QualType RetTy) const; virtual void computeInfo(CGFunctionInfo &FI) const { FI.getReturnInfo() = classifyReturnType(FI.getReturnType()); for (CGFunctionInfo::arg_iterator it = FI.arg_begin(), ie = FI.arg_end(...

...] define i32 @convert(%myType %in) nounwind readonly alwaysinline{ entry: %in.addr = alloca %myType, align 8 store %myType %in, %myType* %in.addr, align 8 %0 = getelementptr inbounds %myType* %in.addr, i32 0, i32 0 %1 = load i64* %0, align 8 %conv = trunc i64 %1 to i32 ret i32 %conv } [ABIArgInfo::getIndirect(0) - Default] %struct.myType = type { i64 } define i32 @convert(%struct.myType* nocapture byval %in) nounwind readonly { entry: %val = getelementptr inbounds %struct.myType* %in, i64 0, i32 0 %0 = load i64* %val, align 8, !tbaa !0 %conv = trunc i64 %0 to i32 ret i32 %conv } [...

...* > > store %myType %in, %myType* %in.addr, align 8**** > > %0 = getelementptr inbounds %myType* %in.addr, i32 0, i32 0**** > > %1 = load i64* %0, align 8**** > > %conv = trunc i64 %1 to i32**** > > ret i32 %conv**** > > }**** > > ** ** > > [ABIArgInfo::getIndirect(0) – Default]**** > > %struct.myType = type { i64 }**** > > ** ** > > define i32 @convert(%struct.myType* nocapture byval %in) nounwind readonly > {**** > > entry:**** > > %val = getelementptr inbounds %struct.myType* %in, i64 0, i32 0**** > >...

...using the corruption of struct when accessed through GDB. This seems to be an ABI problem in clang. The problem seems to be that when we have pass by value of struct (having indirect arguments) stack is not aligned properly. I tried realigning the stack for indirect arguments in(TargetInfo.cpp) - ABIArgInfo X86_32ABIInfo::getIndirectResult(QualType Ty, bool ByVal) ..... if (StackAlign == 0) return ABIArgInfo::getIndirect(4, /*ByVal=*/true, /*Realign=*/true); // Do a realign of stack. ... This seems to have fixed the issue. Also in case we have a lar...

...en accessed through GDB. > This seems to be an ABI problem in clang. > The problem seems to be that when we have pass by value of struct > (having indirect arguments) stack is not aligned properly. > > I tried realigning the stack for indirect arguments in(TargetInfo.cpp) - > > ABIArgInfo X86_32ABIInfo::getIndirectResult(QualType Ty, bool ByVal) > > ..... > if (StackAlign == 0) > return ABIArgInfo::getIndirect(4, /*ByVal=*/true, > /*Realign=*/true); // Do a > realign of stack. > > ... > > > This seems...

...ion signature in the IR is target specific since it already contains some ABI information at this point. I know Mips would use the definition above but other targets may vary. 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. > 2) Does the presence of the signext mean it's imperative to sign > extend, or that extension, only if needed, should be signed? It's an agreement between the caller and callee to ensure the value is...

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

This seems to be another case of PR13303 - since GDB can't figure out where to break for this function based on the debug info (you'll notice when you "break recurse" that it's not breaking on a line or source file, just an address) it's breaking at the very start, before the prologue I'm about to commit a fix to this. On Tue, Dec 4, 2012 at 5:34 AM, Karthik Bhat

In particular, I would for example like to prevent that two fields of type i32 are packed into an i64 parameter. And so on... Thanks! -- Zvonimir

Carl, See clang/lib/CodeGen/TargetInfo.cpp. // FIXME: mingw64-gcc emits 128-bit struct as i128 if (Size <= 128 && (Size & (Size - 1)) == 0) return ABIArgInfo::getDirect(llvm::IntegerType::get(getVMContext(), Size)); It was my workaround, sorry. Please check to tweak the clause (128 to 64) and lemme know. ...Takumi On Tue, Feb 22, 2011 at 7:58 AM, Carl Norum <carl.norum at apple.com> wro...

The MS x64 ABI calling convention (http://msdn.microsoft.com/en-us/library/ms235286(VS.80).aspx) says: Any argument that doesn’t fit in 8 bytes, or is not 1, 2, 4, or 8 bytes, must be passed by reference. Clang isn't doing that for us when passing our triple, x86_64-pc-win32-macho. Here's a simple example program: struct Guid { unsigned int Data1; unsigned

Hi All, I was debugging a clang binary when i found this problem. The following code is complied with clang. typedef struct s { short s; } SVAL; void recurse (SVAL a, int depth) { a.s = --depth; if (depth == 0) return; else recurse(a,depth); } int main () { SVAL s; s.s = 5; recurse (s, 5); return 0; } When i try to access value of a.s in function recurse through gdb(i.e

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.

Objects compiled for the MS-ABI don't conform to it! Data types beyond 64 bit MUST BE returned by the callee via the hidden first argument allocated by the caller, NOT in XMM0! Demo/proof: from this source --- llvm-bug.c --- #ifndef __clang__ typedef struct { unsigned __int64 low; unsigned __int64 high; } __uint128_t; #else __attribute__((ms_abi)) #endif __uint128_t

...or sext the return > value to make it conform to the ABI. You can look at some of the other > classify*Type methods in Clang for how. Would you mind elaborating where to look, specifically? What I'm seeing is that some classify*Type methods select different types, like e.g.: return ABIArgInfo::getDirect(llvm::Type::getInt64Ty(getVMContext())); I was hoping this could be used to implement extension for ABI purposes, but it doesn't look like this will work (with the current infrastructure). If the type specified in the classify*Type method is larger than the actual parameter/return...

...itchCase* const, unsigned int> > >::_M_insert_unique(std::pair<clang::SwitchCase* const, unsigned int> const&) + 6550 19 clang 0x00000001001ead35 clang::BackendConsumer::HandleTranslationUnit(clang::ASTContext&) + 261 20 clang 0x0000000100208358 clang::ABIArgInfo::setCoerceToType(llvm::Type const*) + 952 21 clang 0x00000001001ea05e llvm::DenseMap<clang::CXXRecordDecl const*, long long, llvm::DenseMapInfo<clang::CXXRecordDecl const*>, llvm::DenseMapInfo<long long> >::grow(unsigned int) + 3326 22 clang 0x0000000100054...

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