similar to: [LLVMdev] Lowering formal pointer arguments

Le 15/03/2012 03:07, Akira Hatanaka a écrit : > If you need llvm::Argument, this returns the iterator pointing to the > first argument: > > Function::const_arg_iterator Arg = > DAG.getMachineFunction().getFunction()->arg_begin(); Thanks Akira. Ivan > > On Wed, Mar 14, 2012 at 8:16 AM, Ivan Llopard<ivanllopard at gmail.com> wrote: >> Hi, >> >> How

If you need llvm::Argument, this returns the iterator pointing to the first argument: Function::const_arg_iterator Arg = DAG.getMachineFunction().getFunction()->arg_begin(); On Wed, Mar 14, 2012 at 8:16 AM, Ivan Llopard <ivanllopard at gmail.com> wrote: > Hi, > > How can I get the llvm-type of the formal argument while lowering it ? > > My target needs to map pointer and

Our target also use different registers for pointer and non-pointer parameters. > If you need llvm::Argument, this returns the iterator pointing to the > first argument: DAG.getMachineFunction().getFunction() only works in LowerFormalArguments (there it returns the callee), not in LowerCall (where it returns the caller, rather than the callee). You need to pass more information about the

Hi Patrik, > DAG.getMachineFunction().getFunction() only works in LowerFormalArguments (there it returns the callee), not in LowerCall (where it returns the caller, rather than the callee). You need to pass more information about the function type to LowerCall (besides partial information such as the isVarArg parameter). > > I can provide a patch if you are interested. (Unfortunately,

If no i64 reg classes are registered, then type-legalization will expand a 32b x 32b = 64b multiply node into a 32-bit mult node with two i32 results (for example, SMUL_LOHI). The problem is that there isn't an easy way to have RA assign two consecutive hi/lo registers to the two i32 registers, once the 64-bit result is split into two 32-bit results. Is there a constraint I can use (something

Hi Eli, On 07/05/2012 18:15, Eli Friedman wrote: > On Mon, May 7, 2012 at 5:15 AM, Ivan Llopard<ivanllopard at gmail.com> wrote: >> Hi all, >> >> Tuning my TargetAsmPrinter implementation in the back-end side, I >> discovered that the address space number is not passed down while >> emitting global variables with constant initializers. The information is

On Tue, May 8, 2012 at 4:59 AM, Ivan Llopard <ivanllopard at gmail.com> wrote: > Hi Eli, > > > On 07/05/2012 18:15, Eli Friedman wrote: >> >> On Mon, May 7, 2012 at 5:15 AM, Ivan Llopard<ivanllopard at gmail.com> >>  wrote: >>> >>> Hi all, >>> >>> Tuning my TargetAsmPrinter implementation in the back-end side, I

Hi Akira, Micah, On 05/09/2012 21:44, Akira Hatanaka wrote: > Micah, > > Do you mean we should make GPR64 available to register allocator by > calling addRegisterClass? > > addRegisterClass(MVT::i64, &GPR64RegClass) I have a related question to this thread. Does the RA use target lowering information? Because if it doesn't, you don't need to register your i64 reg

Hi Eli, Thanks for your response. Please see my responses below. On 10/12/2011 00:28, Eli Friedman wrote: > On Fri, Dec 9, 2011 at 4:46 AM, Llopard Ivan<ivanllopard at gmail.com> wrote: >> Hi all, >> >> I am writing a back-end for a processor that has complex type registers. >> It has two functional units to perform complex multiplications. >> From clang,

Hi Ivan, I'm just looking into it now. Thanks for working on this. - Lang. On Tue, May 29, 2012 at 6:50 AM, Ivan Llopard <ivanllopard at gmail.com> wrote: > Hi again, > > Just forgot to add PATCH prefix to my message! Could you please review it ? > > Ivan > > Le 26/05/2012 00:52, Ivan Llopard a écrit : > > Hi, > > > > I have a custom

Hi all, Tuning my TargetAsmPrinter implementation in the back-end side, I discovered that the address space number is not passed down while emitting global variables with constant initializers. The information is dropped at AsmPrinter::EmitGlobalConstant() function call which defaults it to zero. I would like to emit target-dependent asm directives depending on the address space of constant

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

Hi Philip, The error happens when the program finishes and it automatically calls the destructors, so it is not an error specifically inside my program. Here's the full code: #include "llvm/ExecutionEngine/ExecutionEngine.h" #include "llvm/ExecutionEngine/MCJIT.h" #include "llvm/IRReader/IRReader.h" #include "llvm/Support/TargetSelect.h" #include

On 10/12/2011 01:32, Eli Friedman wrote: > On Fri, Dec 9, 2011 at 4:12 PM, Ivan Llopard<ivanllopard at gmail.com> wrote: >> Hi Eli, >> Thanks for your response. Please see my responses below. >> >> >> On 10/12/2011 00:28, Eli Friedman wrote: >>> On Fri, Dec 9, 2011 at 4:46 AM, Llopard Ivan<ivanllopard at gmail.com> >>> wrote:

Hello Job, I managed to resolve this same problem by using custom C++ code since as you mentioned the isSplit flag doesn't help here. There are 2 ways to analyze the arguments of a function: 1) You can get a Function pointer in LowerFormalArguments, and in LowerCall only when Callee can by dyn_casted to a GlobalAddressSDNode. By having this pointer you can then do: for

Hi Jim, Thanks for your response. Le 06/03/2012 22:54, Jim Grosbach a écrit : > Hi Ivan, > On Mar 3, 2012, at 4:48 AM, Ivan Llopard<ivanllopard at gmail.com> wrote: > >> Hi, >> >> I'm facing a problem in llvm while porting it to a new target and I'll >> need some support. >> We have 2 kind of register, one for general purposes (i.e.

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 all, Is there any ongoing work in LLVM/Clang to support fixed-point arithmetic as described in ISO/IEC TR 18037 ? It seems that gcc has support for it since 2007 and it would be useful for us to add such support. Just to get an idea if we decide to work on this, how long would it take to get it implemented ? Regards, Ivan

Hi, I'm facing a problem in my BE while trying to remove certain copies. Here is a code snippet which I would like to optimize %vreg1<def> = READF32r; vRRegs:%vreg1 %vreg2<def> = COPY %vreg1:rsub_h; iRSubRegs:%vreg2 vRRegs:%vreg1 %vreg3<def> = COPY %vreg1:rsub_l; iRSubRegs:%vreg3 vRRegs:%vreg1 This code produces subreg-to-subreg copies but I would like to have direct

Hi, We've a target which has hardware support for zero-overhead loops. Currently, we cannot detect them because the loop unroller is unrolling them before entering into the codegen. Looking at its implementation, it seems that it checks if it is profitable to unroll it or not based on certain parameters. Given that zero cost loops building is based more or less on the same constraints