similar to: [LLVMdev] Calling Convention & Stack Frame

Hi Evan, first off thanks to you and Chris for taking time. On 6 Sep 2007, at 00:57, Evan Cheng wrote: > We'd like to see tail call optimization to be similar to the target > independent lowering of ISD::CALL nodes. These are auto-generated > from ???CallingConv.td files. Some target specific details such as > function address register (ECX in your example) should be coded in

On Dec 18, 2008, at 7:05 PM, Sandeep Patel wrote: > Since there have been no answers, I will have to start at the > beginning. > > One of the first changes I'd like to try is adding the additional > registers and the AAPCS VFP variant calling conventions. Is there a > reason why the ARM Target isn't using the CCState machinery? Please clarify. I am not sure what you

Hi Arnold, Thanks for the patch. Some questions and commons: 1. Have you test it against the llvm test suite? Does it work if fp elimination optimization is turned off? 2. Please follow llvm coding convention and make sure every line fits in 80 columns. 3. enum NameDecorationStyle { None, StdCall, - FastCall + FastCall, + FastCC // the normal fastcc calling convention }; Why is

On 19/07/2007 01:29:18, Seung Jae Lee (lee225 at uiuc.edu) wrote: > Somebody in this dev-list alreday did it with LLVM. I guess you are speaking about Bruno Cardoso Lopes ? I can see there is a MIPS implementation in LLVM repository but it looks like uncomplete (that is, I'm not even sure it can compile any source). What I hope is to have a complete MIPS implementation so I can adapt

Attached is a prototype patch that uses CCState to lower RET nodes in the ARM target. Lowering CALL nodes will come later. This patch does not handle f64 and i64 types. For these types, it would be ideal to request the conversions below: def RetCC_ARM_APCS : CallingConv<[ CCIfType<[f32], CCBitConvertToType<i32>>, CCIfType<[f64], CCBitConvertToType<i64>>,

On Fri, 3 Aug 2007, Rafael Espindola wrote: > Sorry for the delay. I am back from a vacation and have been busy > catching up.... Welcome back :) > That is why I need the types (just for the size). This is necessary to > implement both the current behavior and the correct ABI. Right. > consider the llvm code > --------------------------------------- > %struct.s = type {

Hi, I would like to start a new porting of GlobalIsel for RISCV. An initial patch about GlobalIsel infrastructure for RISCV was ready now: https://reviews.llvm.org/D65219 There is another porting patch https://reviews.llvm.org/D41653 posted by Leslie Zhai at the end of 2017. I have checked with Leslie about the status of this patch.He has stopped developing it since some questions need be

On 27/07/07, Evan Cheng <evan.cheng at apple.com> wrote: > Code generator shouldn't introspect the LLVM type at all, except to > get the size of the type. Anything needed should be encoded by the > front-end. In the short term, please focus on getting parity with > what we already have. This means x86-64 will be wrong, but it > already is. As a second step we can then

Hi, In my LLVM IR I am returning a structure from a function but it gave me an assertion failure when I was trying to compile the resulting bitcode. Specifically, I had following function definition define {i32,i32,i32} @func(i32 a) { ..... ret {i32,i32,i32} %retStruct } llc gave me following assertion failure: Return operand#2 has unhandled type i32 in AnalyzeReturn function On digging

Hi Josef, > Okay, I've done a lot more testing and I now have a .bc file that compiles for x86, sparc, mips but refuses to compile for the mblaze and powerPC backends because of the calling convention. Is there anyone that would know how to fix the microblaze calling convention or point me in the right direction on how to fix it? what does "refuses to compile" mean? I.e. what

Hi Tim, Thank you for the input. I think I follow you. I believe the LowerCall is doing what it needs to do - passing pointer either on the stack or in register as per ABI. The LowerFormalArguments() is where I am stuck. LowerFormalArguments () calls CCInfo.AnalyzeFormalArguments(Ins, CC_XCore), which calls the CC_XCore(). This is where I placed the CCIfByVal<CCPassByVal<0,4>> which

On Dec 27, 2008, at 4:30 AM, Sandeep Patel wrote: > Attached is a prototype patch that uses CCState to lower RET nodes in > the ARM target. Lowering CALL nodes will come later. > > This patch does not handle f64 and i64 types. For these types, it > would be ideal to request the conversions below: i64 isn't Legal on ARM, so it should already be handled. > > > def

> what does "refuses to compile" mean? I.e. what error do you get? > Specifically I get this message when compiling with the default -mattr: Call result #2 has unhandled type i32 UNREACHABLE executed at CallingConvLower.cpp:162! 0 llc 0x0000000100a1e115 PrintStackTrace(void*) + 38 1 llc 0x0000000100a1e6d0 SignalHandler(int) + 254 2

Hi, > I believe the LowerCall is doing what it needs to do - passing pointer either on the stack or in register as per ABI. >From very quick test-cases with no understanding of XCore, that looks plausible. > LowerFormalArguments () calls CCInfo.AnalyzeFormalArguments(Ins, CC_XCore), which calls the CC_XCore(). > This is where I placed the CCIfByVal<CCPassByVal<0,4>>

MachineRegisterInfo is maintaining a list of live-out registers for the MachineFunction. It contains the return value registers, and is typically created by XXXISelLowering::LowerReturn(). Various passes after instruction selection need to look at this list to determine which physical registers are live in return blocks. Eventually, the register allocators copy these live-out registers onto the

Hello, I am working on a backend for a custom ISA that is somewhat similar to the MicroBlaze ISA so I've decided to use that as a starting point. I am trying to compile a custom ray tracer (lots of floating point) and the llvm-g++ frontend generates an fneg instruction which is not supported by the MBlaze backend in the 2.8 release. I added code to emit an fneg assembly instruction and now

Hi everyone, I found that LLVM generates redundant code when calling functions with constant parameters, with optimizations disabled. Consider the following C code snippet: int foo(int x, int y); void bar() { foo(1, 2); foo(3, 4); } Clang/LLVM 6.0 generates the following assembly code: _bar: subl $32, %esp movl $1, %eax movl $2, %ecx movl $1, (%esp) movl $2, 4(%esp) movl %eax, 28(%esp) movl

Hi Robert, > I tried adding to the XCoreCallingConv.td: > CCIfByVal<CCPassByVal<0,4>> // pushes pointer to the stack This looks sensible to me. After that it comes down to cooperation between XCoreISelLowering's LowerFormalArguments and LowerCall functions. LowerFormalArguments is at the beginning of a function and is responsible for taking arguments out of

Hi - help! I have read through previous threads on the subject of 'byval' e.g. https://groups.google.com/forum/#!topicsearchin/llvm-dev/Exact$20meaning$20of$20byval/llvm-dev/cyRZyXcMCNI https://groups.google.com/forum/#!topicsearchin/llvm-dev/$20byval/llvm-dev/uk4uiK93jeM https://groups.google.com/forum/#!topicsearchin/llvm-dev/byval/llvm-dev/46Tv0lSRwBg and read through code

Hi Hidle, 2007/7/19, Hlide <hlide at free.fr>: > > On 19/07/2007 01:29:18, Seung Jae Lee (lee225 at uiuc.edu) wrote: > > Somebody in this dev-list alreday did it with LLVM. > > I guess you are speaking about Bruno Cardoso Lopes ? I can see there is > a MIPS implementation in LLVM repository but it looks like uncomplete > (that is, I'm not even sure it can