Displaying 10 results from an estimated 10 matches for "getdirect".
Did you mean:
jetdirect
2012 Oct 08
1
[LLVMdev] Fwd: Multiply i8 operands promotes to i32
...CodeGenFunction &CGF) const { return 0; }
};
ABIArgInfo MSP430ABIInfo::classifyReturnType(QualType RetTy) const {
if (RetTy->isVoidType())
return ABIArgInfo::getIgnore();
if (isAggregateTypeForABI(RetTy))
return ABIArgInfo::getIndirect(0);
return ABIArgInfo::getDirect();
}
ABIArgInfo MSP430ABIInfo::classifyArgumentType(QualType Ty) const {
if (isAggregateTypeForABI(Ty))
return ABIArgInfo::getIndirect(0);
return ABIArgInfo::getDirect();
}
3) Register your new MSP430ABIInfo class in the TargetCodeGenInfo
constructor inside MSP430TargetCodeGenInfo by rep...
2012 Nov 09
1
[LLVMdev] Loop carried dependence analysis?
...pass. But the flow, anti dependence, etc methods are
> only reporting sequential and not loop carried dependencies. Does LLVM
> support loop carried dependency analysis?
>
> In addition, the distance and direction for dependent instructions always
> have invalid values; Dependence::getDirection() returns DVEntry::ALL which
> is the default value and Dependence::getDistance always returns null.
>
> E.g, for this input loop:
> for (int i = 1; i < 100; i++)
> {
> arr[i] = arr[i-1];
> }
>
> This dependence is reported:
> %1 = load i32* %arrayidx.i, alig...
2012 Nov 09
0
[LLVMdev] Loop carried dependence analysis?
...the
DependenceAnalysis pass. But the flow, anti dependence, etc methods are
only reporting sequential and not loop carried dependencies. Does LLVM
support loop carried dependency analysis?
In addition, the distance and direction for dependent instructions always
have invalid values; Dependence::getDirection() returns DVEntry::ALL which
is the default value and Dependence::getDistance always returns null.
E.g, for this input loop:
for (int i = 1; i < 100; i++)
{
arr[i] = arr[i-1];
}
This dependence is reported:
%1 = load i32* %arrayidx.i, align 4 ---> store i32 %1, i32*
%arrayidx2.i,...
2012 Jun 13
2
[LLVMdev] Structs passed by value
...yType = 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
}
[ABIArgInfo::getExtend(), ABIArgInfo::getDirect(), ABIArgInfo::getExpand()]
define i32 @convert(i64 %in.coerce0) nounwind readnone {
entry:
%conv = trunc i64 %in.coerce0 to i32
ret i32 %conv
}
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20120613/70b...
2011 Feb 22
0
[LLVMdev] Passing structures as pointers, MSVC x64 style
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> wrote:
>
&g...
2012 Jun 14
0
[LLVMdev] Structs passed by value
...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****
>
> }****
>
> ** **
>
> [ABIArgInfo::getExtend(), ABIArgInfo::getDirect(), ABIArgInfo::getExpand()]
> ****
>
> define i32 @convert(i64 %in.coerce0) nounwind readnone {****
>
> entry:****
>
> %conv = trunc i64 %in.coerce0 to i32****
>
> ret i32 %conv****
>
> }****
>
> ** **
>
> ____________________________________________...
2011 Feb 21
2
[LLVMdev] Passing structures as pointers, MSVC x64 style
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
2020 Aug 30
5
BUG: complete misunterstanding of the MS-ABI
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
2012 Oct 23
1
[LLVMdev] [cfe-commits] [PATCH/RFC, PowerPC] Extend 32-bit function arguments / return values
...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 value type,...
2012 Oct 22
4
[LLVMdev] [cfe-commits] [PATCH/RFC, PowerPC] Extend 32-bit function arguments / return values
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