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
Patrik Hägglund H
2014-Sep-10 06:39 UTC
[LLVMdev] Machine Code for different architectures
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
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 > >