Displaying 7 results from an estimated 7 matches similar to: "[LLVMdev] Possible bug in getCallPreservedMask for CallingConv::Intel_OCL_BI"
2010 Mar 03
2
[LLVMdev] [PATCH] New calling convention for use by GHC
Hi all,
As previously mentioned on this list the Haskell compiler GHC has a new
LLVM based back-end. The back-end needs a new calling convention to
efficiently use LLVM and that is what this patch does, just for X86 at
the moment.
Breakdown:
1) Need actual calling convention
Touches:
- include/llvm/CallingConv.h
- lib/Target/X86/X86CallingConv.td
2) Handling new calling
2010 Mar 03
0
[LLVMdev] [PATCH] New calling convention for use by GHC
On Mar 2, 2010, at 5:33 PM, David Terei wrote:
> Hi all,
>
> As previously mentioned on this list the Haskell compiler GHC has a new LLVM based back-end. The back-end needs a new calling convention to efficiently use LLVM and that is what this patch does, just for X86 at the moment.
Nice,
> The GHC developers would love to get this included in LLVM so that we don't need to
2010 Mar 07
1
[LLVMdev] [PATCH] New calling convention for use by GHC
OK, new patch attached. Hopefully in time for 2.7.
Chris Lattner wrote:
> 1) is the GHC calling conv intended to be target specific? If it is x86 specific, it should get an X86 prefix. If not, it should move up to be #10 after Cold.
No its intended to be supported on any platforms that GHC is supported
on, which is just x86 and SPARC at the moment. At the moment I've just
done X86, will
2017 Jul 28
3
Purpose of various register classes in X86 target
Hello Matthias,
On 28 July 2017 at 04:13, Matthias Braun <mbraun at apple.com> wrote:
> It's not that hard in principle:
> - A register class is a set of registers.
> - Virtual Registers have a register class assigned.
> - If you have register constraints (like x86 8bit operations only work on
> al,ah,etc.) then you have to create a new register class to express that.
2009 Feb 05
1
[LLVMdev] CallingConv
Currently with my understanding of using callingconv.td I still need to
lower three functions, FORMAL_ARGUMENTS, CALL, and RET. Is there any
known way to have LLVM automagically generate code from tablegen without
having to custom lower these functions? The reasoning for this is that
all registers are virtual in my backend and I have specified for llvm to
use it's generic dynamic stack
2010 Aug 11
1
[LLVMdev] Unnecessary Win64 stack allocations...
I'm trying to understand the Win64 case of the code below, from X86RegisterInfo.cpp:
// If this is x86-64 and the Red Zone is not disabled, if we are a leaf
// function, and use up to 128 bytes of stack space, don't have a frame
// pointer, calls, or dynamic alloca then we do not need to adjust the
// stack pointer (we fit in the Red Zone).
if (Is64Bit &&
2020 Oct 08
4
__attribute__((apple_abi)): targeting Apple/ARM64 ABI from Linux (and others)
Hello everyone,
I made a quick patch to clang/llvm to introduce an "apple_abi" function attribute
(https://github.com/aguinet/llvm-project/commit/c4905ded3afb3182435df30e527955031cb0d098),
to be able to compile functions for the Apple ARM64 ABI when targeting other ARM64 OSes
(e.g. Linux). This can be seen as the Apple version of the already existing "ms_abi"
attribute.
In