similar to: [RFC] A value-tracking LiveDebugValues implementation

When I use clang on an x86-64 to spit out the LLVM, like this clang -O -S -emit-llvm varargstest.c where varargstest.c looks like this int add_em_up(int count, ...) { va_list ap; int i, sum; va_start(ap, count); sum = 0; for (i = 0; i < count; i++) sum += va_arg(ap, int); va_end(ap); return sum; } I see LLVM that looks like it's been customized for the x86-64, versus

The PowerPC backend on PPC64 for non-Darwin (SVR4 ABI) systems currently has a problem handling integer types smaller than 64 bits. This is because the ABI specifies that these types are zero-extended to 64 bits on the stack and the default logic provided in LegalizeDAG does not use that convention. Specifically, for these targets we have: setOperationAction(ISD::VAARG, MVT::Other, Expand);

On Fri, 23 Mar 2012 09:50:12 +0100 Ivan Llopard <ivanllopard at gmail.com> wrote: > Hi Finkel, > > Le 23/03/2012 05:50, Hal Finkel a écrit : > > The PowerPC backend on PPC64 for non-Darwin (SVR4 ABI) systems > > currently has a problem handling integer types smaller than 64 bits. > > This is because the ABI specifies that these types are > > zero-extended

Le 23/03/2012 17:02, Hal Finkel a écrit : > On Fri, 23 Mar 2012 09:50:12 +0100 > Ivan Llopard<ivanllopard at gmail.com> wrote: > >> Hi Finkel, >> >> Le 23/03/2012 05:50, Hal Finkel a écrit : >>> The PowerPC backend on PPC64 for non-Darwin (SVR4 ABI) systems >>> currently has a problem handling integer types smaller than 64 bits. >>> This

Hi Finkel, Le 23/03/2012 05:50, Hal Finkel a écrit : > The PowerPC backend on PPC64 for non-Darwin (SVR4 ABI) systems > currently has a problem handling integer types smaller than 64 bits. > This is because the ABI specifies that these types are zero-extended to > 64 bits on the stack and the default logic provided in LegalizeDAG does > not use that convention. Specifically, for

Hi Chris, Chris Lattner wrote: > On Tue, 3 Apr 2007, Nicolas Geoffray wrote: > >> A VAARG call requires a lot of computation. Typically the C code for >> va_arg(ap, int) >> > > If you use va_arg in C, are you seeing llvm.vaarg in the output .ll file? > I'm guessing that if you're asking, then no llvm.vaarg is generated. I can not test it on my

Hi, While working some more on the backend, I've added callee register saving and have come across something odd (I assume its because i've not implemented something), this is with optimisations which makes it even more odd : MOV.L [R7+ 12], R1 ; 4-byte Folded Spill MOV.L [R7+ 8], R2 ; 4-byte Folded Spill ADD.L R0,R0 + R1 ADD.L

On Tue, 3 Apr 2007, Nicolas Geoffray wrote: > A VAARG call requires a lot of computation. Typically the C code for > va_arg(ap, int) If you use va_arg in C, are you seeing llvm.vaarg in the output .ll file? -Chris > is: > > int va_arg_gpr(ap_list ap) { > int idx = ap->gpr; > if (idx < 8) { > ap->gpr = idx + 1; > return

I have an llvm ir, which generates the following machine code using llc (llvm 3.0 on win32) after # *** IR Dump After X86 DAG->DAG Instruction Selection ***: The first three lines and the last two lines alone together are used to compute "sin" for some double number. - line 1: move the stack pointer down 8 - line 2: copy the updated stack pointer to a base register - line 3: copy a

Hi,every one. I' in trouble again. I want add a new intrinsic mapping a new instruction. I add the int_x86_max_qb as fllowing: def int_x86_max_qb: GCCBuiltin<"__builtin_x86_max_qb">, Intrinsic<[llvm_i32_ty], [llvm_i32_ty, llvm_i32_ty], [Commutative]>; BUILTIN(__builtin_x86_max_qb, "iii", "") I define the intrinsic as Pseudo instruction,it

Hi Peng, Can you please open a bugzilla and attache the LL file ? Can you please reproduce it on ToT ? Thanks, Nadav On Feb 7, 2013, at 9:08 PM, Peng Cheng <gm4cheng at gmail.com> wrote: > I have an llvm ir, which generates the following machine code using llc (llvm 3.0 on win32) after # *** IR Dump After X86 DAG->DAG Instruction Selection ***: > > The first three lines

Hi everyone, I'm implementing varags handling for PPC32 with the ELF ABI. It is largely more complicated than the Macho ABI or x86 because it manipulates a struct instead of a direct pointer in the stack. You can find the layout of the va_list struct at the end of this mail. A VAARG call requires a lot of computation. Typically the C code for va_arg(ap, int) is: int va_arg_gpr(ap_list

--------- Forwarded Message --------- From： Tianhao Shen <17862703959 at 163.com> Date： 11/14/2018 09:31 To： craig.topper at gmail.com <craig.topper at gmail.com> Subject： Re: [llvm-dev] How to define an instruction Hi, Craig Thank you for replying to me. I guess that you misunderstand my meaning about "can'r run". I just want to run my instruction by LLVM using the

Hi Andrew, Andrew Lenharth wrote: > On 4/2/07, Nicolas Geoffray <nicolas.geoffray at lip6.fr> wrote: > >> Hi everyone, >> >> Currently, when declaring a va_list in llvm, one only needs to do: >> >> %ap = alloca i8 * (Reference : llvm/docs/LangRef.html#int_varargs) >> > > This example is x86 specific. alpha allocas an {sbyte*, int}

Hi，every one. This problem has been bothering me for several days.I really hope that you can help me. I want to add an trinsics in X86. This trinsics can compare two numbers and return the larger. There are the changes I do as fllowing. In /tools/clang/include/clang/Basic/BuiltinsX86.def : BUILTIN(__builtin_x86_max_qb, "iii", "") In include/llvm/IR/IntrinsicsX86.td : let

I am wondering about register allocation when there is a kill flag on the MachineOperand. Do I need to remove the kill flag? This code below is just an example from test\CodeGen\X86\xor.ll # Machine code for function test3: Frame Objects: fi#-2: size=4, align=4, fixed, at location [SP+8] fi#-1: size=4, align=8, fixed, at location [SP+4] Function Live Outs: %EAX BB#0: derived from LLVM BB

Thank you for answering my confusion. I have another questions. If I add really instructions instead intrinsics ,can I reach my purpose? I guess ,the answer is "can't". I don't find the anything about how machine to do about instructions,especially "ALU" instructions. Thank you again, Tianhao Shen On 11/14/2018 13:42，Craig Topper<craig.topper at gmail.com>

Hi, while writing my register allocator, I have come across a case which confuses me because the llvm definition cannot be mapped to machine code. For instance I come across (1) and I reduce it to (2). However a copy instruction cannot move from EDX to CX. What mechanics in LLVM will tell me that I cannot make this move during register allocation, or how can I tell from (1) that I cannot execute

My architecture has an FPU, but uses integer registers to store floating-point values. So each register can store either an int or an IEEE float. I define a register class like this: def GR32 : RegisterClass<"MyArch", [i32, f32], 32, (sequence "R%u", 0, 32)>; So far so good. However, when I write a rule to store a register: def STORE32r : S32< (outs), (ins

I'm generating code for a target that only supports i32 natively. My front end is generating VAARG for accessing varargs parameters. The problem is that I get an assert when I compile this: #include <stdarg.h> int main(va_list ap) { typedef double type; type tmp; tmp = va_arg(ap, type); } Bitcode: ; ModuleID = 't0056.bc' target datalayout =