[llvm-dev] [RFC] Tensilica Xtensa (ESP32) backend

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
12 messages Options
Reply | Threaded
Open this post in threaded view
|

[llvm-dev] [RFC] Tensilica Xtensa (ESP32) backend

Tsur Herman via llvm-dev

Hello,

I'm from Espressif Systems company, software department. Our company develops processors based on Xtensa architecture like ESP32 and ESP8266. We propose the integration of a backend targeting Xtensa architecture.

We started to develop LLVM Xtensa backend almost a year ago. The reason was that we saw a demand from our large developers community. Currently only GNU compiler supports Xtensa architecture. The company has approved me to develop and maintain Xtensa backend.

We already have the initial version of the Xtensa backend, based on LLVM Compiler Infrastructure, release 6.0.0. It was successfully tested using GCC torture testsuite and multiple applications.

These are the links to LLVM and Clang repositories.

https://github.com/espressif/llvm-xtensa
https://github.com/espressif/clang-xtensa

Current version can generate Xtensa assembly code as output, not object files yet, and has to be used together with GNU Binutils and GCC-built libraries to create object and binary files.

Xtensa backend features implemented:

- Xtensa target description(Xtnesa.td, XtensaTargetMachine.cpp, XtensaSubTarget.cpp)
- ISA desciption (XtensaInstrInfo.td, XtensaInstrFormats.td, XtensaREgisterInfo.td)
- Xtensa Call ABI (XtensaCallingConv.td, XtensaFrameLowering.cpp)
- ASM printer/parser(XtesaAsmPrinter.cpp, XtensaInstrPrinter.cpp, XtensaAsmParser.cpp)

Xtensa architecture features implemented in compiler:

- Xtensa Core Architecture instructions
- Code Density option
- Windowed Register option
- Floating-Point Coprocessor option
- Boolean option (only a subset of instructions)
- Thread Pointer option
- atomic operations

Current Xtensa target list:

- support Xtensa LX6 target (ESP32) by default

Compiler optimization levels include O0/O1/O2/O3/Os options.

With LLVM community approval, my next plans will be

- rebasing on the upstream version of LLVM.
- object code generation (XtensaMC package)
- implement test cases
- support for LX106 target (ESP8266)
- improvements of generated code performance
- support for zero-overhead loop option
- MAC16 option

There were some discussions about implementation of the Xtensa backend and attempt to implement it:
http://lists.llvm.org/pipermail/llvm-dev/2018-July/124789.html
http://lists.llvm.org/pipermail/llvm-dev/2018-April/122676.html

Also there were attempts to implement a LLVM Xtensa backend, but recently I found only one actual link:
https://github.com/jdiez17/llvm-xtensa

All comments and suggesions are welcome!

Andrei Safronov


_______________________________________________
LLVM Developers mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
Reply | Threaded
Open this post in threaded view
|

Re: [llvm-dev] [RFC] Tensilica Xtensa (ESP32) backend

Tsur Herman via llvm-dev
This is welcome news to me.

We use ESP8266 (yes, not ESP32, but your future plans include the older
MCU) for an IOT system in conjunction with RPi machines. The language
that we target in preference is Go, but obviously currently use C++ for
the ESPs. We'd like to use Go for the ESPs via the tinygo.org project,
but this depends on clang/llvm support of the MCU target.

thanks
Dan Kortschak

I recently asked here about the prior work https://lists.llvm.org/piper
mail/llvm-dev/2019-February/130169.html.

On Wed, 2019-03-06 at 14:29 +0300, Andrei Safronov via llvm-dev wrote:

> Hello,
>
> I'm from Espressif Systems company, software department. Our company 
> develops processors based on Xtensa architecture like ESP32 and
> ESP8266. 
> We propose the integration of a backend targeting Xtensa
> architecture.
>
> We started to develop LLVM Xtensa backend almost a year ago. The
> reason 
> was that we saw a demand from our large developers community.
> Currently 
> only GNU compiler supports Xtensa architecture. The company has
> approved 
> me to develop and maintain Xtensa backend.
>
> We already have the initial version of the Xtensa backend, based on
> LLVM 
> Compiler Infrastructure, release 6.0.0. It was successfully tested
> using 
> GCC torture testsuite and multiple applications.
>
> These are the links to LLVM and Clang repositories.
>
> https://github.com/espressif/llvm-xtensa
> https://github.com/espressif/clang-xtensa
>
> Current version can generate Xtensa assembly code as output, not
> object 
> files yet, and has to be used together with GNU Binutils and GCC-
> built 
> libraries to create object and binary files.
>
> Xtensa backend features implemented:
>
> - Xtensa target description(Xtnesa.td, XtensaTargetMachine.cpp, 
> XtensaSubTarget.cpp)
> - ISA desciption (XtensaInstrInfo.td, XtensaInstrFormats.td, 
> XtensaREgisterInfo.td)
> - Xtensa Call ABI (XtensaCallingConv.td, XtensaFrameLowering.cpp)
> - ASM printer/parser(XtesaAsmPrinter.cpp, XtensaInstrPrinter.cpp, 
> XtensaAsmParser.cpp)
>
> Xtensa architecture features implemented in compiler:
>
> - Xtensa Core Architecture instructions
> - Code Density option
> - Windowed Register option
> - Floating-Point Coprocessor option
> - Boolean option (only a subset of instructions)
> - Thread Pointer option
> - atomic operations
>
> Current Xtensa target list:
>
> - support Xtensa LX6 target (ESP32) by default
>
> Compiler optimization levels include O0/O1/O2/O3/Os options.
>
> With LLVM community approval, my next plans will be
>
> - rebasing on the upstream version of LLVM.
> - object code generation (XtensaMC package)
> - implement test cases
> - support for LX106 target (ESP8266)
> - improvements of generated code performance
> - support for zero-overhead loop option
> - MAC16 option
>
> There were some discussions about implementation of the Xtensa
> backend 
> and attempt to implement it:
> http://lists.llvm.org/pipermail/llvm-dev/2018-July/124789.html
> http://lists.llvm.org/pipermail/llvm-dev/2018-April/122676.html
>
> Also there were attempts to implement a LLVM Xtensa backend, but 
> recently I found only one actual link:
> https://github.com/jdiez17/llvm-xtensa
>
> All comments and suggesions are welcome!
>
> Andrei Safronov
>
> _______________________________________________
> LLVM Developers mailing list
> [hidden email]
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
_______________________________________________
LLVM Developers mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
Reply | Threaded
Open this post in threaded view
|

Re: [llvm-dev] [RFC] Tensilica Xtensa (ESP32) backend

Tsur Herman via llvm-dev
In reply to this post by Tsur Herman via llvm-dev
Sounds like a good idea to me! It seems there's plenty of interest in this architecture.

From a quick glance at your existing code, it looks like you haven't added any llvm tests -- that'll certainly be a requirement.  But barring some particular reason why it's not feasible, I think that having object-file generation working is basically considered a requirement for new architectures. (It's also not clear to me why you cannot with your current code, it looks like instruction definitions already have their encodings specified and such).

If you haven't yet, you ought to check out at the great patch series that Alex Bradbury created to demonstrate the addition of RISCV support to LLVM, as a guide to what order it probably makes sense to make the changes, and how to split the changes into reviewable pieces for upstreaming: https://github.com/lowRISC/riscv-llvm

I'd suggest as your first step, you should work on getting just the Asm/MC layer rebased onto trunk and working for the core ISA for your target -- able to parse and print assembly, both textual and object files -- with a full suite of test-cases at each step. Just like the first ~10 patches in the above patchset.



On Wed, Mar 6, 2019 at 6:29 AM Andrei Safronov via llvm-dev <[hidden email]> wrote:

Hello,

I'm from Espressif Systems company, software department. Our company develops processors based on Xtensa architecture like ESP32 and ESP8266. We propose the integration of a backend targeting Xtensa architecture.

We started to develop LLVM Xtensa backend almost a year ago. The reason was that we saw a demand from our large developers community. Currently only GNU compiler supports Xtensa architecture. The company has approved me to develop and maintain Xtensa backend.

We already have the initial version of the Xtensa backend, based on LLVM Compiler Infrastructure, release 6.0.0. It was successfully tested using GCC torture testsuite and multiple applications.

These are the links to LLVM and Clang repositories.

https://github.com/espressif/llvm-xtensa
https://github.com/espressif/clang-xtensa

Current version can generate Xtensa assembly code as output, not object files yet, and has to be used together with GNU Binutils and GCC-built libraries to create object and binary files.

Xtensa backend features implemented:

- Xtensa target description(Xtnesa.td, XtensaTargetMachine.cpp, XtensaSubTarget.cpp)
- ISA desciption (XtensaInstrInfo.td, XtensaInstrFormats.td, XtensaREgisterInfo.td)
- Xtensa Call ABI (XtensaCallingConv.td, XtensaFrameLowering.cpp)
- ASM printer/parser(XtesaAsmPrinter.cpp, XtensaInstrPrinter.cpp, XtensaAsmParser.cpp)

Xtensa architecture features implemented in compiler:

- Xtensa Core Architecture instructions
- Code Density option
- Windowed Register option
- Floating-Point Coprocessor option
- Boolean option (only a subset of instructions)
- Thread Pointer option
- atomic operations

Current Xtensa target list:

- support Xtensa LX6 target (ESP32) by default

Compiler optimization levels include O0/O1/O2/O3/Os options.

With LLVM community approval, my next plans will be

- rebasing on the upstream version of LLVM.
- object code generation (XtensaMC package)
- implement test cases
- support for LX106 target (ESP8266)
- improvements of generated code performance
- support for zero-overhead loop option
- MAC16 option

There were some discussions about implementation of the Xtensa backend and attempt to implement it:
http://lists.llvm.org/pipermail/llvm-dev/2018-July/124789.html
http://lists.llvm.org/pipermail/llvm-dev/2018-April/122676.html

Also there were attempts to implement a LLVM Xtensa backend, but recently I found only one actual link:
https://github.com/jdiez17/llvm-xtensa

All comments and suggesions are welcome!

Andrei Safronov

_______________________________________________
LLVM Developers mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

_______________________________________________
LLVM Developers mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
Reply | Threaded
Open this post in threaded view
|

Re: [llvm-dev] [RFC] Tensilica Xtensa (ESP32) backend

Tsur Herman via llvm-dev
In reply to this post by Tsur Herman via llvm-dev
Hello,

Thank you for your interest. We are planning to add support for ESP8266
in the near future.

Best regards,
Andrey Safronov
07.03.2019 0:42, Dan Kortschak пишет:

> This is welcome news to me.
>
> We use ESP8266 (yes, not ESP32, but your future plans include the older
> MCU) for an IOT system in conjunction with RPi machines. The language
> that we target in preference is Go, but obviously currently use C++ for
> the ESPs. We'd like to use Go for the ESPs via the tinygo.org project,
> but this depends on clang/llvm support of the MCU target.
>
> thanks
> Dan Kortschak
>
> I recently asked here about the prior work https://lists.llvm.org/piper
> mail/llvm-dev/2019-February/130169.html.
>
> On Wed, 2019-03-06 at 14:29 +0300, Andrei Safronov via llvm-dev wrote:
>> Hello,
>>
>> I'm from Espressif Systems company, software department. Our company
>> develops processors based on Xtensa architecture like ESP32 and
>> ESP8266.
>> We propose the integration of a backend targeting Xtensa
>> architecture.
>>
>> We started to develop LLVM Xtensa backend almost a year ago. The
>> reason
>> was that we saw a demand from our large developers community.
>> Currently
>> only GNU compiler supports Xtensa architecture. The company has
>> approved
>> me to develop and maintain Xtensa backend.
>>
>> We already have the initial version of the Xtensa backend, based on
>> LLVM
>> Compiler Infrastructure, release 6.0.0. It was successfully tested
>> using
>> GCC torture testsuite and multiple applications.
>>
>> These are the links to LLVM and Clang repositories.
>>
>> https://github.com/espressif/llvm-xtensa
>> https://github.com/espressif/clang-xtensa
>>
>> Current version can generate Xtensa assembly code as output, not
>> object
>> files yet, and has to be used together with GNU Binutils and GCC-
>> built
>> libraries to create object and binary files.
>>
>> Xtensa backend features implemented:
>>
>> - Xtensa target description(Xtnesa.td, XtensaTargetMachine.cpp,
>> XtensaSubTarget.cpp)
>> - ISA desciption (XtensaInstrInfo.td, XtensaInstrFormats.td,
>> XtensaREgisterInfo.td)
>> - Xtensa Call ABI (XtensaCallingConv.td, XtensaFrameLowering.cpp)
>> - ASM printer/parser(XtesaAsmPrinter.cpp, XtensaInstrPrinter.cpp,
>> XtensaAsmParser.cpp)
>>
>> Xtensa architecture features implemented in compiler:
>>
>> - Xtensa Core Architecture instructions
>> - Code Density option
>> - Windowed Register option
>> - Floating-Point Coprocessor option
>> - Boolean option (only a subset of instructions)
>> - Thread Pointer option
>> - atomic operations
>>
>> Current Xtensa target list:
>>
>> - support Xtensa LX6 target (ESP32) by default
>>
>> Compiler optimization levels include O0/O1/O2/O3/Os options.
>>
>> With LLVM community approval, my next plans will be
>>
>> - rebasing on the upstream version of LLVM.
>> - object code generation (XtensaMC package)
>> - implement test cases
>> - support for LX106 target (ESP8266)
>> - improvements of generated code performance
>> - support for zero-overhead loop option
>> - MAC16 option
>>
>> There were some discussions about implementation of the Xtensa
>> backend
>> and attempt to implement it:
>> http://lists.llvm.org/pipermail/llvm-dev/2018-July/124789.html
>> http://lists.llvm.org/pipermail/llvm-dev/2018-April/122676.html
>>
>> Also there were attempts to implement a LLVM Xtensa backend, but
>> recently I found only one actual link:
>> https://github.com/jdiez17/llvm-xtensa
>>
>> All comments and suggesions are welcome!
>>
>> Andrei Safronov
>>
>> _______________________________________________
>> LLVM Developers mailing list
>> [hidden email]
>> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
_______________________________________________
LLVM Developers mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
Reply | Threaded
Open this post in threaded view
|

Re: [llvm-dev] [RFC] Tensilica Xtensa (ESP32) backend

Tsur Herman via llvm-dev
Is this target the one interested in `alignof(char) != sizeof(char)`,
`alignof(char) == 4`?  https://reviews.llvm.org/D58811

On Thu, Mar 7, 2019 at 4:13 PM Andrei Safronov via llvm-dev
<[hidden email]> wrote:

>
> Hello,
>
> Thank you for your interest. We are planning to add support for ESP8266
> in the near future.
>
> Best regards,
> Andrey Safronov
> 07.03.2019 0:42, Dan Kortschak пишет:
> > This is welcome news to me.
> >
> > We use ESP8266 (yes, not ESP32, but your future plans include the older
> > MCU) for an IOT system in conjunction with RPi machines. The language
> > that we target in preference is Go, but obviously currently use C++ for
> > the ESPs. We'd like to use Go for the ESPs via the tinygo.org project,
> > but this depends on clang/llvm support of the MCU target.
> >
> > thanks
> > Dan Kortschak
> >
> > I recently asked here about the prior work https://lists.llvm.org/piper
> > mail/llvm-dev/2019-February/130169.html.
> >
> > On Wed, 2019-03-06 at 14:29 +0300, Andrei Safronov via llvm-dev wrote:
> >> Hello,
> >>
> >> I'm from Espressif Systems company, software department. Our company
> >> develops processors based on Xtensa architecture like ESP32 and
> >> ESP8266.
> >> We propose the integration of a backend targeting Xtensa
> >> architecture.
> >>
> >> We started to develop LLVM Xtensa backend almost a year ago. The
> >> reason
> >> was that we saw a demand from our large developers community.
> >> Currently
> >> only GNU compiler supports Xtensa architecture. The company has
> >> approved
> >> me to develop and maintain Xtensa backend.
> >>
> >> We already have the initial version of the Xtensa backend, based on
> >> LLVM
> >> Compiler Infrastructure, release 6.0.0. It was successfully tested
> >> using
> >> GCC torture testsuite and multiple applications.
> >>
> >> These are the links to LLVM and Clang repositories.
> >>
> >> https://github.com/espressif/llvm-xtensa
> >> https://github.com/espressif/clang-xtensa
> >>
> >> Current version can generate Xtensa assembly code as output, not
> >> object
> >> files yet, and has to be used together with GNU Binutils and GCC-
> >> built
> >> libraries to create object and binary files.
> >>
> >> Xtensa backend features implemented:
> >>
> >> - Xtensa target description(Xtnesa.td, XtensaTargetMachine.cpp,
> >> XtensaSubTarget.cpp)
> >> - ISA desciption (XtensaInstrInfo.td, XtensaInstrFormats.td,
> >> XtensaREgisterInfo.td)
> >> - Xtensa Call ABI (XtensaCallingConv.td, XtensaFrameLowering.cpp)
> >> - ASM printer/parser(XtesaAsmPrinter.cpp, XtensaInstrPrinter.cpp,
> >> XtensaAsmParser.cpp)
> >>
> >> Xtensa architecture features implemented in compiler:
> >>
> >> - Xtensa Core Architecture instructions
> >> - Code Density option
> >> - Windowed Register option
> >> - Floating-Point Coprocessor option
> >> - Boolean option (only a subset of instructions)
> >> - Thread Pointer option
> >> - atomic operations
> >>
> >> Current Xtensa target list:
> >>
> >> - support Xtensa LX6 target (ESP32) by default
> >>
> >> Compiler optimization levels include O0/O1/O2/O3/Os options.
> >>
> >> With LLVM community approval, my next plans will be
> >>
> >> - rebasing on the upstream version of LLVM.
> >> - object code generation (XtensaMC package)
> >> - implement test cases
> >> - support for LX106 target (ESP8266)
> >> - improvements of generated code performance
> >> - support for zero-overhead loop option
> >> - MAC16 option
> >>
> >> There were some discussions about implementation of the Xtensa
> >> backend
> >> and attempt to implement it:
> >> http://lists.llvm.org/pipermail/llvm-dev/2018-July/124789.html
> >> http://lists.llvm.org/pipermail/llvm-dev/2018-April/122676.html
> >>
> >> Also there were attempts to implement a LLVM Xtensa backend, but
> >> recently I found only one actual link:
> >> https://github.com/jdiez17/llvm-xtensa
> >>
> >> All comments and suggesions are welcome!
> >>
> >> Andrei Safronov
> >>
> >> _______________________________________________
> >> LLVM Developers mailing list
> >> [hidden email]
> >> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
> _______________________________________________
> LLVM Developers mailing list
> [hidden email]
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
_______________________________________________
LLVM Developers mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
Reply | Threaded
Open this post in threaded view
|

Re: [llvm-dev] [RFC] Tensilica Xtensa (ESP32) backend

Tsur Herman via llvm-dev
In reply to this post by Tsur Herman via llvm-dev

Hello, James,

Thank you very much for your advices! The next step in compiler development on Espressif is object file generation. There are no essential problems with this step, it will be implemented in nearest future. Currently Xtensa backend is able to print and parse assembly, I used about 1300 tests from gcc torture testsuite and GNU binutils to debug assembly output and now all tests could be compiled and executed successfully. So, with object file generation Xtensa backend will be significally closer to be used in real projects, but I'm agree that it is not ready yet for upstreaming. There is no llvm tests and also it is hard to review such big amount of code. So I need to do something with these issues.

I reviewed integration process of  the RISC-V backend, which you mentioned. Did I understand correctly that you suggest to split the proposed Xtensa backend into ordered patches, each of which defines some backend functionality (starting from Asm/MC layer)that is easy to review? And also include in each patch some set of tests to verify such functionality?

Best regards,
Andrei Safronov

07.03.2019 1:31, James Y Knight пишет:
Sounds like a good idea to me! It seems there's plenty of interest in this architecture.

From a quick glance at your existing code, it looks like you haven't added any llvm tests -- that'll certainly be a requirement.  But barring some particular reason why it's not feasible, I think that having object-file generation working is basically considered a requirement for new architectures. (It's also not clear to me why you cannot with your current code, it looks like instruction definitions already have their encodings specified and such).

If you haven't yet, you ought to check out at the great patch series that Alex Bradbury created to demonstrate the addition of RISCV support to LLVM, as a guide to what order it probably makes sense to make the changes, and how to split the changes into reviewable pieces for upstreaming: https://github.com/lowRISC/riscv-llvm

I'd suggest as your first step, you should work on getting just the Asm/MC layer rebased onto trunk and working for the core ISA for your target -- able to parse and print assembly, both textual and object files -- with a full suite of test-cases at each step. Just like the first ~10 patches in the above patchset.



On Wed, Mar 6, 2019 at 6:29 AM Andrei Safronov via llvm-dev <[hidden email]> wrote:

Hello,

I'm from Espressif Systems company, software department. Our company develops processors based on Xtensa architecture like ESP32 and ESP8266. We propose the integration of a backend targeting Xtensa architecture.

We started to develop LLVM Xtensa backend almost a year ago. The reason was that we saw a demand from our large developers community. Currently only GNU compiler supports Xtensa architecture. The company has approved me to develop and maintain Xtensa backend.

We already have the initial version of the Xtensa backend, based on LLVM Compiler Infrastructure, release 6.0.0. It was successfully tested using GCC torture testsuite and multiple applications.

These are the links to LLVM and Clang repositories.

https://github.com/espressif/llvm-xtensa
https://github.com/espressif/clang-xtensa

Current version can generate Xtensa assembly code as output, not object files yet, and has to be used together with GNU Binutils and GCC-built libraries to create object and binary files.

Xtensa backend features implemented:

- Xtensa target description(Xtnesa.td, XtensaTargetMachine.cpp, XtensaSubTarget.cpp)
- ISA desciption (XtensaInstrInfo.td, XtensaInstrFormats.td, XtensaREgisterInfo.td)
- Xtensa Call ABI (XtensaCallingConv.td, XtensaFrameLowering.cpp)
- ASM printer/parser(XtesaAsmPrinter.cpp, XtensaInstrPrinter.cpp, XtensaAsmParser.cpp)

Xtensa architecture features implemented in compiler:

- Xtensa Core Architecture instructions
- Code Density option
- Windowed Register option
- Floating-Point Coprocessor option
- Boolean option (only a subset of instructions)
- Thread Pointer option
- atomic operations

Current Xtensa target list:

- support Xtensa LX6 target (ESP32) by default

Compiler optimization levels include O0/O1/O2/O3/Os options.

With LLVM community approval, my next plans will be

- rebasing on the upstream version of LLVM.
- object code generation (XtensaMC package)
- implement test cases
- support for LX106 target (ESP8266)
- improvements of generated code performance
- support for zero-overhead loop option
- MAC16 option

There were some discussions about implementation of the Xtensa backend and attempt to implement it:
http://lists.llvm.org/pipermail/llvm-dev/2018-July/124789.html
http://lists.llvm.org/pipermail/llvm-dev/2018-April/122676.html

Also there were attempts to implement a LLVM Xtensa backend, but recently I found only one actual link:
https://github.com/jdiez17/llvm-xtensa

All comments and suggesions are welcome!

Andrei Safronov

_______________________________________________
LLVM Developers mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

_______________________________________________
LLVM Developers mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
Reply | Threaded
Open this post in threaded view
|

Re: [llvm-dev] [RFC] Tensilica Xtensa (ESP32) backend

Tsur Herman via llvm-dev
Very welcome news! :))

I use an experimental back end on LLVM at the moment for AVR chips but it has never had Atmel/Microchip official support or assistance so it’s not as good as it could be.

With Tensilica giving official backing to your LLVM back end you will make already very attractive chips even more amazing. You guys are killing it! :))

FYI, I’m targeting AVR compiled from the Swift language front end, building a standard library, etc. aimed at low power, simple microcontrollers. ESP32/ESP8266 would be a very natural fit for our community. I have already had many customers ask if it’s possible.  Until now I had to tell them there was not yet a supported back end. This is great news!

Carl

On 7 Mar 2019, at 17:47, Andrei Safronov via llvm-dev <[hidden email]> wrote:

Hello, James,

Thank you very much for your advices! The next step in compiler development on Espressif is object file generation. There are no essential problems with this step, it will be implemented in nearest future. Currently Xtensa backend is able to print and parse assembly, I used about 1300 tests from gcc torture testsuite and GNU binutils to debug assembly output and now all tests could be compiled and executed successfully. So, with object file generation Xtensa backend will be significally closer to be used in real projects, but I'm agree that it is not ready yet for upstreaming. There is no llvm tests and also it is hard to review such big amount of code. So I need to do something with these issues.

I reviewed integration process of  the RISC-V backend, which you mentioned. Did I understand correctly that you suggest to split the proposed Xtensa backend into ordered patches, each of which defines some backend functionality (starting from Asm/MC layer)that is easy to review? And also include in each patch some set of tests to verify such functionality?

Best regards,
Andrei Safronov

07.03.2019 1:31, James Y Knight пишет:
Sounds like a good idea to me! It seems there's plenty of interest in this architecture.

From a quick glance at your existing code, it looks like you haven't added any llvm tests -- that'll certainly be a requirement.  But barring some particular reason why it's not feasible, I think that having object-file generation working is basically considered a requirement for new architectures. (It's also not clear to me why you cannot with your current code, it looks like instruction definitions already have their encodings specified and such).

If you haven't yet, you ought to check out at the great patch series that Alex Bradbury created to demonstrate the addition of RISCV support to LLVM, as a guide to what order it probably makes sense to make the changes, and how to split the changes into reviewable pieces for upstreaming: https://github.com/lowRISC/riscv-llvm

I'd suggest as your first step, you should work on getting just the Asm/MC layer rebased onto trunk and working for the core ISA for your target -- able to parse and print assembly, both textual and object files -- with a full suite of test-cases at each step. Just like the first ~10 patches in the above patchset.



On Wed, Mar 6, 2019 at 6:29 AM Andrei Safronov via llvm-dev <[hidden email]> wrote:

Hello,

I'm from Espressif Systems company, software department. Our company develops processors based on Xtensa architecture like ESP32 and ESP8266. We propose the integration of a backend targeting Xtensa architecture.

We started to develop LLVM Xtensa backend almost a year ago. The reason was that we saw a demand from our large developers community. Currently only GNU compiler supports Xtensa architecture. The company has approved me to develop and maintain Xtensa backend.

We already have the initial version of the Xtensa backend, based on LLVM Compiler Infrastructure, release 6.0.0. It was successfully tested using GCC torture testsuite and multiple applications.

These are the links to LLVM and Clang repositories.

https://github.com/espressif/llvm-xtensa
https://github.com/espressif/clang-xtensa

Current version can generate Xtensa assembly code as output, not object files yet, and has to be used together with GNU Binutils and GCC-built libraries to create object and binary files.

Xtensa backend features implemented:

- Xtensa target description(Xtnesa.td, XtensaTargetMachine.cpp, XtensaSubTarget.cpp)
- ISA desciption (XtensaInstrInfo.td, XtensaInstrFormats.td, XtensaREgisterInfo.td)
- Xtensa Call ABI (XtensaCallingConv.td, XtensaFrameLowering.cpp)
- ASM printer/parser(XtesaAsmPrinter.cpp, XtensaInstrPrinter.cpp, XtensaAsmParser.cpp)

Xtensa architecture features implemented in compiler:

- Xtensa Core Architecture instructions
- Code Density option
- Windowed Register option
- Floating-Point Coprocessor option
- Boolean option (only a subset of instructions)
- Thread Pointer option
- atomic operations

Current Xtensa target list:

- support Xtensa LX6 target (ESP32) by default

Compiler optimization levels include O0/O1/O2/O3/Os options.

With LLVM community approval, my next plans will be

- rebasing on the upstream version of LLVM.
- object code generation (XtensaMC package)
- implement test cases
- support for LX106 target (ESP8266)
- improvements of generated code performance
- support for zero-overhead loop option
- MAC16 option

There were some discussions about implementation of the Xtensa backend and attempt to implement it:
http://lists.llvm.org/pipermail/llvm-dev/2018-July/124789.html
http://lists.llvm.org/pipermail/llvm-dev/2018-April/122676.html

Also there were attempts to implement a LLVM Xtensa backend, but recently I found only one actual link:
https://github.com/jdiez17/llvm-xtensa

All comments and suggesions are welcome!

Andrei Safronov

_______________________________________________
LLVM Developers mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
_______________________________________________
LLVM Developers mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev


_______________________________________________
LLVM Developers mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
Reply | Threaded
Open this post in threaded view
|

Re: [llvm-dev] [RFC] Tensilica Xtensa (ESP32) backend

Tsur Herman via llvm-dev
I'm hoping we'll see future Espressif chips using RISC-V -- they are a
Founding Gold member of the RISC-V Foundation.

On Thu, Mar 7, 2019 at 2:55 PM LLVM Mailing List via llvm-dev
<[hidden email]> wrote:

>
> Very welcome news! :))
>
> I use an experimental back end on LLVM at the moment for AVR chips but it has never had Atmel/Microchip official support or assistance so it’s not as good as it could be.
>
> With Tensilica giving official backing to your LLVM back end you will make already very attractive chips even more amazing. You guys are killing it! :))
>
> FYI, I’m targeting AVR compiled from the Swift language front end, building a standard library, etc. aimed at low power, simple microcontrollers. ESP32/ESP8266 would be a very natural fit for our community. I have already had many customers ask if it’s possible.  Until now I had to tell them there was not yet a supported back end. This is great news!
>
> Carl
>
> On 7 Mar 2019, at 17:47, Andrei Safronov via llvm-dev <[hidden email]> wrote:
>
> Hello, James,
>
> Thank you very much for your advices! The next step in compiler development on Espressif is object file generation. There are no essential problems with this step, it will be implemented in nearest future. Currently Xtensa backend is able to print and parse assembly, I used about 1300 tests from gcc torture testsuite and GNU binutils to debug assembly output and now all tests could be compiled and executed successfully. So, with object file generation Xtensa backend will be significally closer to be used in real projects, but I'm agree that it is not ready yet for upstreaming. There is no llvm tests and also it is hard to review such big amount of code. So I need to do something with these issues.
>
> I reviewed integration process of  the RISC-V backend, which you mentioned. Did I understand correctly that you suggest to split the proposed Xtensa backend into ordered patches, each of which defines some backend functionality (starting from Asm/MC layer)that is easy to review? And also include in each patch some set of tests to verify such functionality?
>
> Best regards,
> Andrei Safronov
>
> 07.03.2019 1:31, James Y Knight пишет:
>
> Sounds like a good idea to me! It seems there's plenty of interest in this architecture.
>
> From a quick glance at your existing code, it looks like you haven't added any llvm tests -- that'll certainly be a requirement.  But barring some particular reason why it's not feasible, I think that having object-file generation working is basically considered a requirement for new architectures. (It's also not clear to me why you cannot with your current code, it looks like instruction definitions already have their encodings specified and such).
>
> If you haven't yet, you ought to check out at the great patch series that Alex Bradbury created to demonstrate the addition of RISCV support to LLVM, as a guide to what order it probably makes sense to make the changes, and how to split the changes into reviewable pieces for upstreaming: https://github.com/lowRISC/riscv-llvm
>
> I'd suggest as your first step, you should work on getting just the Asm/MC layer rebased onto trunk and working for the core ISA for your target -- able to parse and print assembly, both textual and object files -- with a full suite of test-cases at each step. Just like the first ~10 patches in the above patchset.
>
>
>
> On Wed, Mar 6, 2019 at 6:29 AM Andrei Safronov via llvm-dev <[hidden email]> wrote:
>>
>>
>> Hello,
>>
>> I'm from Espressif Systems company, software department. Our company develops processors based on Xtensa architecture like ESP32 and ESP8266. We propose the integration of a backend targeting Xtensa architecture.
>>
>> We started to develop LLVM Xtensa backend almost a year ago. The reason was that we saw a demand from our large developers community. Currently only GNU compiler supports Xtensa architecture. The company has approved me to develop and maintain Xtensa backend.
>>
>> We already have the initial version of the Xtensa backend, based on LLVM Compiler Infrastructure, release 6.0.0. It was successfully tested using GCC torture testsuite and multiple applications.
>>
>> These are the links to LLVM and Clang repositories.
>>
>> https://github.com/espressif/llvm-xtensa
>> https://github.com/espressif/clang-xtensa
>>
>> Current version can generate Xtensa assembly code as output, not object files yet, and has to be used together with GNU Binutils and GCC-built libraries to create object and binary files.
>>
>> Xtensa backend features implemented:
>>
>> - Xtensa target description(Xtnesa.td, XtensaTargetMachine.cpp, XtensaSubTarget.cpp)
>> - ISA desciption (XtensaInstrInfo.td, XtensaInstrFormats.td, XtensaREgisterInfo.td)
>> - Xtensa Call ABI (XtensaCallingConv.td, XtensaFrameLowering.cpp)
>> - ASM printer/parser(XtesaAsmPrinter.cpp, XtensaInstrPrinter.cpp, XtensaAsmParser.cpp)
>>
>> Xtensa architecture features implemented in compiler:
>>
>> - Xtensa Core Architecture instructions
>> - Code Density option
>> - Windowed Register option
>> - Floating-Point Coprocessor option
>> - Boolean option (only a subset of instructions)
>> - Thread Pointer option
>> - atomic operations
>>
>> Current Xtensa target list:
>>
>> - support Xtensa LX6 target (ESP32) by default
>>
>> Compiler optimization levels include O0/O1/O2/O3/Os options.
>>
>> With LLVM community approval, my next plans will be
>>
>> - rebasing on the upstream version of LLVM.
>> - object code generation (XtensaMC package)
>> - implement test cases
>> - support for LX106 target (ESP8266)
>> - improvements of generated code performance
>> - support for zero-overhead loop option
>> - MAC16 option
>>
>> There were some discussions about implementation of the Xtensa backend and attempt to implement it:
>> http://lists.llvm.org/pipermail/llvm-dev/2018-July/124789.html
>> http://lists.llvm.org/pipermail/llvm-dev/2018-April/122676.html
>>
>> Also there were attempts to implement a LLVM Xtensa backend, but recently I found only one actual link:
>> https://github.com/jdiez17/llvm-xtensa
>>
>> All comments and suggesions are welcome!
>>
>> Andrei Safronov
>>
>> _______________________________________________
>> LLVM Developers mailing list
>> [hidden email]
>> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
> _______________________________________________
> LLVM Developers mailing list
> [hidden email]
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
>
> _______________________________________________
> LLVM Developers mailing list
> [hidden email]
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
_______________________________________________
LLVM Developers mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
Reply | Threaded
Open this post in threaded view
|

Re: [llvm-dev] [RFC] Tensilica Xtensa (ESP32) backend

Tsur Herman via llvm-dev
In reply to this post by Tsur Herman via llvm-dev

Hello Andrei,

 

Thank you for the LLVM Xtensa work and the post. Cisco Systems would be glad to support any upstreaming effort for this work in terms of reviews, tests, object file generation, further development, etc.

 

Best Regards,

Anmol P. Paralkar

 

From: llvm-dev <[hidden email]> on behalf of Andrei Safronov via llvm-dev <[hidden email]>
Reply-To: Andrei Safronov <[hidden email]>
Date: Wednesday, March 6, 2019 at 5:30 AM
To: "[hidden email]" <[hidden email]>
Subject: [llvm-dev] [RFC] Tensilica Xtensa (ESP32) backend

 

Hello,

I'm from Espressif Systems company, software department. Our company develops processors based on Xtensa architecture like ESP32 and ESP8266. We propose the integration of a backend targeting Xtensa architecture.

We started to develop LLVM Xtensa backend almost a year ago. The reason was that we saw a demand from our large developers community. Currently only GNU compiler supports Xtensa architecture. The company has approved me to develop and maintain Xtensa backend.

We already have the initial version of the Xtensa backend, based on LLVM Compiler Infrastructure, release 6.0.0. It was successfully tested using GCC torture testsuite and multiple applications.

These are the links to LLVM and Clang repositories.

https://github.com/espressif/llvm-xtensa
https://github.com/espressif/clang-xtensa

Current version can generate Xtensa assembly code as output, not object files yet, and has to be used together with GNU Binutils and GCC-built libraries to create object and binary files.

Xtensa backend features implemented:

- Xtensa target description(Xtnesa.td, XtensaTargetMachine.cpp, XtensaSubTarget.cpp)
- ISA desciption (XtensaInstrInfo.td, XtensaInstrFormats.td, XtensaREgisterInfo.td)
- Xtensa Call ABI (XtensaCallingConv.td, XtensaFrameLowering.cpp)
- ASM printer/parser(XtesaAsmPrinter.cpp, XtensaInstrPrinter.cpp, XtensaAsmParser.cpp)

Xtensa architecture features implemented in compiler:

- Xtensa Core Architecture instructions
- Code Density option
- Windowed Register option
- Floating-Point Coprocessor option
- Boolean option (only a subset of instructions)
- Thread Pointer option
- atomic operations

Current Xtensa target list:

- support Xtensa LX6 target (ESP32) by default

Compiler optimization levels include O0/O1/O2/O3/Os options.

With LLVM community approval, my next plans will be

- rebasing on the upstream version of LLVM.
- object code generation (XtensaMC package)
- implement test cases
- support for LX106 target (ESP8266)
- improvements of generated code performance
- support for zero-overhead loop option
- MAC16 option

There were some discussions about implementation of the Xtensa backend and attempt to implement it:
http://lists.llvm.org/pipermail/llvm-dev/2018-July/124789.html
http://lists.llvm.org/pipermail/llvm-dev/2018-April/122676.html

Also there were attempts to implement a LLVM Xtensa backend, but recently I found only one actual link:
https://github.com/jdiez17/llvm-xtensa

All comments and suggesions are welcome!

Andrei Safronov


_______________________________________________
LLVM Developers mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
Reply | Threaded
Open this post in threaded view
|

Re: [llvm-dev] [RFC] Tensilica Xtensa (ESP32) backend

Tsur Herman via llvm-dev
In reply to this post by Tsur Herman via llvm-dev


On Thu, Mar 7, 2019 at 12:47 PM Andrei Safronov <[hidden email]> wrote:

Hello, James,

Thank you very much for your advices! The next step in compiler development on Espressif is object file generation. There are no essential problems with this step, it will be implemented in nearest future. Currently Xtensa backend is able to print and parse assembly, I used about 1300 tests from gcc torture testsuite and GNU binutils to debug assembly output and now all tests could be compiled and executed successfully. So, with object file generation Xtensa backend will be significally closer to be used in real projects, but I'm agree that it is not ready yet for upstreaming. There is no llvm tests and also it is hard to review such big amount of code. So I need to do something with these issues.

I reviewed integration process of  the RISC-V backend, which you mentioned. Did I understand correctly that you suggest to split the proposed Xtensa backend into ordered patches, each of which defines some backend functionality (starting from Asm/MC layer)that is easy to review? And also include in each patch some set of tests to verify such functionality?

Yes, exactly.

It's not important to follow exactly the same breakup as the RISCV target, but it makes sense to follow roughly the same order of work.

That is, the overall stages you'll want to tackle are going to be something like:
1. Initial addition of the target, triple parsing, etc. (riscv patches #2 through #4)
2. Working MC for the baseline ISA, (#5 through #11).
3. Codegen for the baseline ISA (#12-#32)
4. MC layer for ISA extensions (#33-#41)
5. Codegen for ISA extensions, and further fixes throughout (#42-...)

Having patches that are small enough to be usefully-reviewable is very helpful, and each patch should have a full set of test-cases included testing its functionality (as much as is feasible).

But it's also important to be able to see enough of the implementation to have the necessary context to sanely review. So, that's why I suggest that your initial goal should be to create a set of patches fully-implementing just the first two items on that list, and post them for review at the same time. After that's committed, move on to extracting patches for further functionality, adding tests, and posting for review as you go.

Best regards,
Andrei Safronov

07.03.2019 1:31, James Y Knight пишет:
Sounds like a good idea to me! It seems there's plenty of interest in this architecture.

From a quick glance at your existing code, it looks like you haven't added any llvm tests -- that'll certainly be a requirement.  But barring some particular reason why it's not feasible, I think that having object-file generation working is basically considered a requirement for new architectures. (It's also not clear to me why you cannot with your current code, it looks like instruction definitions already have their encodings specified and such).

If you haven't yet, you ought to check out at the great patch series that Alex Bradbury created to demonstrate the addition of RISCV support to LLVM, as a guide to what order it probably makes sense to make the changes, and how to split the changes into reviewable pieces for upstreaming: https://github.com/lowRISC/riscv-llvm

I'd suggest as your first step, you should work on getting just the Asm/MC layer rebased onto trunk and working for the core ISA for your target -- able to parse and print assembly, both textual and object files -- with a full suite of test-cases at each step. Just like the first ~10 patches in the above patchset.



On Wed, Mar 6, 2019 at 6:29 AM Andrei Safronov via llvm-dev <[hidden email]> wrote:

Hello,

I'm from Espressif Systems company, software department. Our company develops processors based on Xtensa architecture like ESP32 and ESP8266. We propose the integration of a backend targeting Xtensa architecture.

We started to develop LLVM Xtensa backend almost a year ago. The reason was that we saw a demand from our large developers community. Currently only GNU compiler supports Xtensa architecture. The company has approved me to develop and maintain Xtensa backend.

We already have the initial version of the Xtensa backend, based on LLVM Compiler Infrastructure, release 6.0.0. It was successfully tested using GCC torture testsuite and multiple applications.

These are the links to LLVM and Clang repositories.

https://github.com/espressif/llvm-xtensa
https://github.com/espressif/clang-xtensa

Current version can generate Xtensa assembly code as output, not object files yet, and has to be used together with GNU Binutils and GCC-built libraries to create object and binary files.

Xtensa backend features implemented:

- Xtensa target description(Xtnesa.td, XtensaTargetMachine.cpp, XtensaSubTarget.cpp)
- ISA desciption (XtensaInstrInfo.td, XtensaInstrFormats.td, XtensaREgisterInfo.td)
- Xtensa Call ABI (XtensaCallingConv.td, XtensaFrameLowering.cpp)
- ASM printer/parser(XtesaAsmPrinter.cpp, XtensaInstrPrinter.cpp, XtensaAsmParser.cpp)

Xtensa architecture features implemented in compiler:

- Xtensa Core Architecture instructions
- Code Density option
- Windowed Register option
- Floating-Point Coprocessor option
- Boolean option (only a subset of instructions)
- Thread Pointer option
- atomic operations

Current Xtensa target list:

- support Xtensa LX6 target (ESP32) by default

Compiler optimization levels include O0/O1/O2/O3/Os options.

With LLVM community approval, my next plans will be

- rebasing on the upstream version of LLVM.
- object code generation (XtensaMC package)
- implement test cases
- support for LX106 target (ESP8266)
- improvements of generated code performance
- support for zero-overhead loop option
- MAC16 option

There were some discussions about implementation of the Xtensa backend and attempt to implement it:
http://lists.llvm.org/pipermail/llvm-dev/2018-July/124789.html
http://lists.llvm.org/pipermail/llvm-dev/2018-April/122676.html

Also there were attempts to implement a LLVM Xtensa backend, but recently I found only one actual link:
https://github.com/jdiez17/llvm-xtensa

All comments and suggesions are welcome!

Andrei Safronov

_______________________________________________
LLVM Developers mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

_______________________________________________
LLVM Developers mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
Reply | Threaded
Open this post in threaded view
|

Re: [llvm-dev] [RFC] Tensilica Xtensa (ESP32) backend

Tsur Herman via llvm-dev
Hello, James,

Thank you for your explanations, this is really helpful information. I
will include this stages(or maybe similar) of integration process into
my near-term plan and will inform you about progress in implementation.

Best regards, Andrei Safronov

09.03.2019 2:12, James Y Knight пишет:

> Yes, exactly.
>
> It's not important to follow exactly the same breakup as the RISCV
> target, but it makes sense to follow roughly the same order of work.
>
> That is, the overall stages you'll want to tackle are going to be
> something like:
> 1. Initial addition of the target, triple parsing, etc. (riscv patches
> #2 through #4)
> 2. Working MC for the baseline ISA, (#5 through #11).
> 3. Codegen for the baseline ISA (#12-#32)
> 4. MC layer for ISA extensions (#33-#41)
> 5. Codegen for ISA extensions, and further fixes throughout (#42-...)
>
> Having patches that are small enough to be usefully-reviewable is very
> helpful, and each patch should have a full set of test-cases included
> testing its functionality (as much as is feasible).
>
> But it's also important to be able to see enough of the implementation
> to have the necessary context to sanely review. So, that's why I
> suggest that your initial goal should be to create a set of patches
> fully-implementing just the first two items on that list, and post
> them for review at the same time. After that's committed, move on to
> extracting patches for further functionality, adding tests, and
> posting for review as you go.
_______________________________________________
LLVM Developers mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
Reply | Threaded
Open this post in threaded view
|

Re: [llvm-dev] [RFC] Tensilica Xtensa (ESP32) backend

Tsur Herman via llvm-dev
In reply to this post by Tsur Herman via llvm-dev
Hello Anmol,

Thank you for your support. I think that community help could accelerate integration of backend, so I will keep in mind your suggestions. By the way it will useful to know what kind of task do you solve with Xtensa processors and also which  Xtensa configuration do you use(of cause if it is not confidential information). Such information could help to tune some aspects of the Xtensa backend.

Best regards,
Andrei Safronov
09.03.2019 1:44, Anmol Paralkar (anmparal) пишет:

Hello Andrei,

 

Thank you for the LLVM Xtensa work and the post. Cisco Systems would be glad to support any upstreaming effort for this work in terms of reviews, tests, object file generation, further development, etc.

 

Best Regards,

Anmol P. Paralkar

 

From: llvm-dev [hidden email] on behalf of Andrei Safronov via llvm-dev [hidden email]
Reply-To: Andrei Safronov [hidden email]
Date: Wednesday, March 6, 2019 at 5:30 AM
To: [hidden email] [hidden email]
Subject: [llvm-dev] [RFC] Tensilica Xtensa (ESP32) backend

 

Hello,

I'm from Espressif Systems company, software department. Our company develops processors based on Xtensa architecture like ESP32 and ESP8266. We propose the integration of a backend targeting Xtensa architecture.

We started to develop LLVM Xtensa backend almost a year ago. The reason was that we saw a demand from our large developers community. Currently only GNU compiler supports Xtensa architecture. The company has approved me to develop and maintain Xtensa backend.

We already have the initial version of the Xtensa backend, based on LLVM Compiler Infrastructure, release 6.0.0. It was successfully tested using GCC torture testsuite and multiple applications.

These are the links to LLVM and Clang repositories.

https://github.com/espressif/llvm-xtensa
https://github.com/espressif/clang-xtensa

Current version can generate Xtensa assembly code as output, not object files yet, and has to be used together with GNU Binutils and GCC-built libraries to create object and binary files.

Xtensa backend features implemented:

- Xtensa target description(Xtnesa.td, XtensaTargetMachine.cpp, XtensaSubTarget.cpp)
- ISA desciption (XtensaInstrInfo.td, XtensaInstrFormats.td, XtensaREgisterInfo.td)
- Xtensa Call ABI (XtensaCallingConv.td, XtensaFrameLowering.cpp)
- ASM printer/parser(XtesaAsmPrinter.cpp, XtensaInstrPrinter.cpp, XtensaAsmParser.cpp)

Xtensa architecture features implemented in compiler:

- Xtensa Core Architecture instructions
- Code Density option
- Windowed Register option
- Floating-Point Coprocessor option
- Boolean option (only a subset of instructions)
- Thread Pointer option
- atomic operations

Current Xtensa target list:

- support Xtensa LX6 target (ESP32) by default

Compiler optimization levels include O0/O1/O2/O3/Os options.

With LLVM community approval, my next plans will be

- rebasing on the upstream version of LLVM.
- object code generation (XtensaMC package)
- implement test cases
- support for LX106 target (ESP8266)
- improvements of generated code performance
- support for zero-overhead loop option
- MAC16 option

There were some discussions about implementation of the Xtensa backend and attempt to implement it:
http://lists.llvm.org/pipermail/llvm-dev/2018-July/124789.html
http://lists.llvm.org/pipermail/llvm-dev/2018-April/122676.html

Also there were attempts to implement a LLVM Xtensa backend, but recently I found only one actual link:
https://github.com/jdiez17/llvm-xtensa

All comments and suggesions are welcome!

Andrei Safronov


_______________________________________________
LLVM Developers mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev