[LLVMdev] Machine Code for different architectures

Wed Sep 10 00:40:29 PDT 2014

Hi Patrik

Thanks again. I'll catch up with you later (I hope!), when myself or a
colleague require any of those patches, or further advice.

thanks
Matt

On Wed, 2014-09-10 at 06:39 +0000, Patrik Hägglund H wrote:
> 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
> 
> 