similar to: [LLVMdev] Data/Address registers

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.

On Mar 7, 2012, at 6:23 AM, Ivan Llopard <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

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. arithmetic, > comparisons, etc.) and the other for memory addressing. OK. Separate register classes should be able

Le 07/03/2012 17:36, Jim Grosbach a écrit : > On Mar 7, 2012, at 6:23 AM, Ivan Llopard<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: >>>

On Mar 14, 2012, at 7:07 AM, Ivan Llopard wrote: > Le 07/03/2012 17:36, Jim Grosbach a écrit : >> On Mar 7, 2012, at 6:23 AM, Ivan Llopard<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,

Salut Ivan, On Fri, Jun 1, 2012 at 7:22 AM, Ivan Llopard <ivanllopard at gmail.com> wrote: > Hi Sebastian, > > Le 25/05/2012 18:54, Sebastian Pop a écrit : >> On Thu, May 24, 2012 at 5:40 PM, Sebastian Pop<spop at codeaurora.org>  wrote: >>> On Thu, May 24, 2012 at 5:06 PM, Hal Finkel<hfinkel at anl.gov>  wrote: >>>> Sebastian,

Hi Ivan, On Tue, May 22, 2012 at 5:09 PM, Ivan Llopard <ivanllopard at gmail.com> wrote: > Hi Sebastian, > > On 22/05/2012 23:25, Sebastian Pop wrote: >> So my question is how do we specify that for most of the operations i8 >> should be promoted to i32 and that only a few logical operations are >> legal on i8? > > I think the combo

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,

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 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

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:

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

Salut Sebastian! On 01/06/2012 18:19, Sebastian Pop wrote: > Salut Ivan, > > On Fri, Jun 1, 2012 at 7:22 AM, Ivan Llopard<ivanllopard at gmail.com> wrote: >> Hi Sebastian, >> >> Le 25/05/2012 18:54, Sebastian Pop a écrit : >>> On Thu, May 24, 2012 at 5:40 PM, Sebastian Pop<spop at codeaurora.org> wrote: >>>> On Thu, May 24, 2012 at

On Sun, Jun 3, 2012 at 7:11 AM, Ivan Llopard <ivanllopard at gmail.com> wrote: >> So the solution that I was investigating looks like this: >> >>      for (unsigned int i = 0; i<  ISD::BUILTIN_OP_END; ++i) { >>        switch (i) { >>        // By default all operations on i8 have to be promoted to i32. >>        default: >>        

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 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 all, >>> >>> I am writing

Hi, On Tue, May 22, 2012 at 11:35 PM, Sebastian Pop <spop at codeaurora.org> wrote: > Hi Ivan, > > On Tue, May 22, 2012 at 5:09 PM, Ivan Llopard <ivanllopard at gmail.com> wrote: >> Hi Sebastian, >> >> On 22/05/2012 23:25, Sebastian Pop wrote: >>> So my question is how do we specify that for most of the operations i8 >>> should be promoted

Hi Sebastian, Le 25/05/2012 18:54, Sebastian Pop a écrit : > On Thu, May 24, 2012 at 5:40 PM, Sebastian Pop<spop at codeaurora.org> wrote: >> On Thu, May 24, 2012 at 5:06 PM, Hal Finkel<hfinkel at anl.gov> wrote: >>> Sebastian, >>> >>> First, it might be useful to look at what is done in the PowerPC >>> backend. PPC also has condition

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 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