[LLVMdev] Machine Code for different architectures

Tue Sep 9 12:31:00 PDT 2014

Hi Matt,

Another problem, specific for DWARF, is that in some places we want to have "target byte size" (for all target-dependent debug information) and in other places 8-bit byte size (for target-independent encoding of data - DWARF4 chapter 7). This means that, for us, some assembler-emitting functions need to be able to handle _both_ 8-bit bytes and 16-bit bytes. We have solved this by optionally changing some parameters to passing sizes in bits, rather than bytes.  However, support of debug information is far from finished for our target.

/Patrik Hägglund

-----Original Message-----
From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Patrik Hägglund H
Sent: den 9 september 2014 20:55
To: Matthew Gardiner
Cc: Bruce Hoult; Prakash Premkumar; llvmdev
Subject: Re: [LLVMdev] Machine Code for different architectures

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

_______________________________________________
LLVM Developers mailing list
LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev