[LLVMdev] Machine Code for different architectures

Tue Sep 9 23:39:15 PDT 2014

Hi Matt,

> When you mentioned addition of i24 - would that facilitate this
> architecture to claim that it's bytes are 24-bits in size?

No, adding i24 to the set of machine value types (MVTs), just say that we may have a register of that size (which our target has).

Our solution to specify the byte size is to extend the DataLayout class with a new field BitsPerByte, and a corresponding entry ("B16") in the datalayout string. This is used to which specify the byte size to 8 by default, and to 16 for our target. The BitsPerByte field is then used to parameterize the byte size all over the code. 

/Patrik Hägglund

-----Original Message-----
From: Matthew Gardiner [mailto:mg11 at csr.com] 
Sent: den 10 september 2014 08:15
To: Patrik Hägglund H
Cc: Bruce Hoult; Prakash Premkumar; llvmdev; Johnny Val
Subject: Re: [LLVMdev] Machine Code for different architectures

Hi Patrik,

Thanks for this note. It's encouraging to read there has been some
provision made for non-8-bit bytes. I'm not a compiler/backend expert,
(although maybe I'll need to be soon!), so I won't look at the patches
right now, however may at some stage in the future myself or colleague
may request these patches from yourself.

Yes, our 24-bit architectures have non-power-of-2 register sizes.

When you mentioned addition of i24 - would that facilitate this
architecture to claim that it's bytes are 24-bits in size? (Sorry for
being vague, but I'm a debugger person currently...)

thanks again for your help,
Matt  

On Tue, 2014-09-09 at 18:55 +0000, Patrik Hägglund H wrote:
> Hi Matt,
> 
> We maintain a set of patches to the LLVM codebase for 16-bit bytes, and
> non-power-of-2 register sizes. Support for non-power-of-2 register sizes
> and the addition of new machine value types, such as i24, is a "medium-sized"
> patch set. Support for 16-bit bytes is a quite large patch set,
> and it may be even larger after cleanup. (Usually, we just need to
> parameterize the byte size, or replace a size in bytes with a size in bits,
> but for a few instances, we currently have switch statements, handling 8-bit
> and 16-bit byte size separately, and leaving other sizes unimplemented.)
> 
> We currently don't use the code from any other LLVM project,
> such as clang or lldb.
> 
> Our plan is to someday clean up the LLVM patches, and submit them upstream.
> In the meantime, I can to provide them upon request.
> 
> /Patrik Hägglund
> 
> -----Original Message-----
> From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Matthew Gardiner
> Sent: den 9 september 2014 14:20
> To: Johnny Val
> Cc: Bruce Hoult; Prakash Premkumar; llvmdev
> Subject: Re: [LLVMdev] Machine Code for different architectures
> 
> Hi Johnny,
> 
> Thanks for this - particularly the tip about cfe-dev. I'm currently
> trying to coerce lldb to debug these type of architectures (our
> current toolchain already outputs good dwarf info). However, I'm
> struggling since lldb has just assumes that the size of a byte is
> universally 8-bits. At some stage, I *think* at some stage we'd like to
> derive a compiler, from the "same code-base" (i.e. llvm) and I
> wondered how tricky this would be.
> 
> Matt    
> 
> On Tue, 9 Sep 2014 11:49:01 +0100
> Johnny Val <johnnydval at gmail.com> wrote:
> 
> > Hi Matthew,
> > 
> > The byte==8 bits is more of a Clang issue rather than an LLVM issue. I
> > believe your bigger issue will be the fact that you would need to make
> > i24's a legal type in your backend, which as far as I know (unless
> > something has changed recently), is a _big_ job. I briefly looked
> > into it at one point, and decided to leave it for another day.
> > 
> > I am also unsure how hard byte=8bits is backed into Clang. You might
> > want to ask cfe-dev.
> > 
> > I hope that helps.
> > 
> > Johnny
> > 
> > On Tue, Sep 9, 2014 at 7:41 AM, Matthew Gardiner <mg11 at csr.com> wrote:
> > 
> > > Hi,
> > >
> > > We have some DSP architectures (kalimba) which have 24-bits as their
> > > "minimum addressable unit". So this means that the sizeof a char
> > > (and an int and a short for that matter) is 24-bits.
> > >
> > > I quickly read the posted link WritingAnLLVMBackend.html but did not
> > > see an obvious answer to the following question:
> > >
> > > Is it possible to write a backend that faithfully represents these
> > > architectures or is sizeof_byte==8 bits baked into to llvm?
> > >
> > > Does anyone have any views on the above?
> > >
> > > thanks
> > > Matthew Gardiner
> > >
> > >
> > > On Tue, 9 Sep 2014 18:21:01 +1200
> > > Bruce Hoult <bruce at hoult.org> wrote:
> > >
> > > > http://llvm.org/docs/WritingAnLLVMBackend.html
> > > >
> > > >
> > > > On Tue, Sep 9, 2014 at 6:09 PM, Prakash Premkumar
> > > > <prakash.prax at gmail.com> wrote:
> > > >
> > > > > How does LLVM generate machine code for different architectures?
> > > > > For example, the machine code for x86 and amd will vary.
> > > > >
> > > > > How does LLVM convert its IR to machine code for different
> > > > > architectures.Can you please explain the approach? Is it just
> > > > > write two different programs for two different architectures
> > > > > and pass a flag to the compiler based on which machine code you
> > > > > want to generate?
> > > > >
> > > > > Thanks a lot for your explanations.
> > > > >
> > > > > Thanks
> > > > > Prakash
> > > > >
> > > > > _______________________________________________
> > > > > LLVM Developers mailing list
> > > > > LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> > > > > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
> > > > >
> > > > >
> > > >
> > > >
> > > >  To report this email as spam click
> > > > https://www.mailcontrol.com/sr/MZbqvYs5QwJvpeaetUwhCQ== .
> > >
> > >
> > >
> > > Member of the CSR plc group of companies. CSR plc registered in
> > > England and Wales, registered number 4187346, registered office
> > > Churchill House, Cambridge Business Park, Cowley Road, Cambridge,
> > > CB4 0WZ, United Kingdom More information can be found at
> > > www.csr.com. Keep up to date with CSR on our technical blog,
> > > www.csr.com/blog, CSR people blog, www.csr.com/people, YouTube,
> > > www.youtube.com/user/CSRplc, Facebook,
> > > www.facebook.com/pages/CSR/191038434253534, or follow us on Twitter
> > > at www.twitter.com/CSR_plc. New for 2014, you can now access the
> > > wide range of products powered by aptX at www.aptx.com.
> > > _______________________________________________
> > > LLVM Developers mailing list
> > > LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> > > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
> > >
> 
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev