llvm dev - Feb 2017 - Status of the AVR backend

Hey all,

It’s been a while since the last update in November, so here’s another one
Changes since November Close to Rust support

A few people have been working on integrating the AVR backend into the Rust
<https://www.rust-lang.org/> programming language. This has mostly been
work on supporting LLVM 4.0
<https://github.com/rust-lang/rust/issues/37609>
.

Once the final LLVM 4.0 tag is made, we can update emscripten, integrate it
into Rust, and then add a small amount of code to the compiler to enable
support.

Take a look at Jake Goulding’s avr-rust/arduino
<https://github.com/avr-rust/arduino> project for a really nice proof of
concept.
Clang support

At this point, you can compile some decently-sized programs directly to ELF
object files. It is still necessary to use the GNU AVR linker because we
don’t have any support for AVR inside the compiler-rt support library.

On top of this, we need to add logic to Clang so that it passes the correct
C runtime library (crt0, ctc1, ..) to the linker.

In order to successfully compile the Arduino core library, we need to add
support for the ‘weak’ linkage attribute, and support the ‘progmem’
attribute for data that should reside in program flash memory.
Experimental buildbot

We’ve gained a buildbot here
<http://lab.llvm.org:8014/builders/llvm-avr-linux> on the staging
buildmaster. It does not send emails to anyone other than myself, but it
will help keep the test suite green!
Relax memory operation pass

A pass was added in D27650 <https://reviews.llvm.org/D27650> that allows
us
to correctly emit loads/stores to addresses of the form ‘pointer+offset’
where the offset is larger than 63 bytes.

This would stop us from lowering functions which had more than 63 bytes of
data on the stack.
Next on the agenda LLVM linker support

A long time ago we used to have a fork of LLD which added support for AVR
ELF binaries.

The stale repository is here <https://github.com/avr-llvm/lld>.

Now that LLD is somewhat more stable, it would be really cool to see this
picked up again.
Links

   - A list of all AVR-related patches that have been comitted
   <https://reviews.llvm.org/search/query/ZVuiT4mCLrl6/#R>
   - All open bugs for the backend
  
<https://llvm.org/bugs/buglist.cgi?product=libraries&component=Backend%3A%20AVR&resolution=---&list_id=111982>

​
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20170209/9efce505/attachment.html>

On Wed, Feb 8, 2017 at 11:13 PM, Dylan McKay via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> Hey all,
>
> It’s been a while since the last update in November, so here’s another one
> Changes since November Close to Rust support
>
> A few people have been working on integrating the AVR backend into the
> Rust <https://www.rust-lang.org/> programming language. This has
mostly
> been work on supporting LLVM 4.0
> <https://github.com/rust-lang/rust/issues/37609>.
>
> Once the final LLVM 4.0 tag is made, we can update emscripten, integrate
> it into Rust, and then add a small amount of code to the compiler to enable
> support.
>
> Take a look at Jake Goulding’s avr-rust/arduino
> <https://github.com/avr-rust/arduino> project for a really nice proof
of
> concept.
> Clang support
>
> At this point, you can compile some decently-sized programs directly to
> ELF object files. It is still necessary to use the GNU AVR linker because
> we don’t have any support for AVR inside the compiler-rt support library.
>
> On top of this, we need to add logic to Clang so that it passes the
> correct C runtime library (crt0, ctc1, ..) to the linker.
>
> In order to successfully compile the Arduino core library, we need to add
> support for the ‘weak’ linkage attribute, and support the ‘progmem’
> attribute for data that should reside in program flash memory.
> Experimental buildbot
>
> We’ve gained a buildbot here
> <http://lab.llvm.org:8014/builders/llvm-avr-linux> on the staging
> buildmaster. It does not send emails to anyone other than myself, but it
> will help keep the test suite green!
> Relax memory operation pass
>
> A pass was added in D27650 <https://reviews.llvm.org/D27650> that
allows
> us to correctly emit loads/stores to addresses of the form ‘pointer+offset’
> where the offset is larger than 63 bytes.
>
> This would stop us from lowering functions which had more than 63 bytes of
> data on the stack.
> Next on the agenda LLVM linker support
>
> A long time ago we used to have a fork of LLD which added support for AVR
> ELF binaries.
>
> The stale repository is here <https://github.com/avr-llvm/lld>.
>
> Now that LLD is somewhat more stable, it would be really cool to see this
> picked up again.
>
You want to take a look at ELF/Target.cpp in which all
architecture-dependent code is written. You usually have to add a few
hundred lines of code to that file to support a new architecture.

I think one thing you'd find useful in LLD is that LLD is always a
cross-linker. Any LLD build supports all the architectures it supports.
There's no build-time configuration to enable/disable targets. So, once you
add a AVR support, you can use it from anywhere.
> Links
>
>    - A list of all AVR-related patches that have been comitted
>    <https://reviews.llvm.org/search/query/ZVuiT4mCLrl6/#R>
>    - All open bugs for the backend
>   
<https://llvm.org/bugs/buglist.cgi?product=libraries&component=Backend%3A%20AVR&resolution=---&list_id=111982>
>
> ​
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20170210/eca20b42/attachment.html>