similar to: [LLVMdev] Address space information dropped

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 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 > dropped at AsmPrinter::EmitGlobalConstant() function call which defaults

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

Thanks for your quick response Joerg. We have a very small test case where there is global array and its address space attribute specified like in the following code const int __attribute__((address_space(256))) fangle[13] = {2341, 4681, 7022, 9362, 11703, 1403,16384, 18725, 21065, 23406, 25746, 28087, 30427}; I need to put its initializer in another memory because it has a different

Le 07/05/2012 17:15, Joerg Sonnenberger a écrit : > On Mon, May 07, 2012 at 05:15:59PM +0200, Ivan Llopard wrote: >> Thanks for your quick response Joerg. >> >> We have a very small test case where there is global array and its >> address space attribute specified like in the following code >> >> const int __attribute__((address_space(256))) fangle[13] =

On Mon, May 07, 2012 at 05:15:59PM +0200, Ivan Llopard wrote: > Thanks for your quick response Joerg. > > We have a very small test case where there is global array and its > address space attribute specified like in the following code > > const int __attribute__((address_space(256))) fangle[13] = > {2341, 4681, 7022, 9362, 11703, 1403,16384, > 18725, 21065, 23406,

On Tue, May 08, 2012 at 12:57:15AM +0200, Ivan Llopard wrote: > Le 07/05/2012 17:15, Joerg Sonnenberger a écrit : > >On Mon, May 07, 2012 at 05:15:59PM +0200, Ivan Llopard wrote: > >>Thanks for your quick response Joerg. > >> > >>We have a very small test case where there is global array and its > >>address space attribute specified like in the

On Mon, May 07, 2012 at 02:15:16PM +0200, Ivan Llopard wrote: > I would like to emit target-dependent asm directives depending on the > address space of constant initializers. Is there another method to > implement this feature ? I'm not sure I understand what your problem is. Can you provide an example of what you see and what you expect, please? Joerg

Le 08/05/2012 20:44, Eli Friedman a écrit : > 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

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

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

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:

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, How can I get the llvm-type of the formal argument while lowering it ? My target needs to map pointer and non-pointer parameters to different registers. In addition, parameter lowering is address space dependent (another reason why I need such information). Looking at the DAGBuilder, I found that it is dropping it when translating llvm-types to BE types. Even if the base type is saved

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

Hi Hal, On 21/11/2012 22:38, Hal Finkel wrote: > ----- Original Message ----- >> From: "Ivan Llopard" <ivanllopard at gmail.com> >> To: "LLVM Developers Mailing List" <llvmdev at cs.uiuc.edu> >> Sent: Wednesday, November 21, 2012 10:31:07 AM >> Subject: [LLVMdev] Disable loop unroll pass >> >> Hi, >> >> We've a