Moving the AVR backend out of experimental

Hi,

There was a thread a few days ago about the expectations for experimental targets. At the moment, the only experimental target is AVR. It’s been in the tree for a long time now, and generally seems well-behaved.

Should we just make it a normal target?

Nico

+better dylanmckay address

What do you see as the pros and cons of making it a stable target? Does anyone else have any concerns about doing so?

-Chris

Pros:

  • LLVM’s release binaries contain AVR support :slight_smile:
  • It’d happen to remove the only backend that’s currently marked experimental, which imho makes the build config easier to understand

Cons:

  • Everyone gets to pay the cost for maintaining AVR for cross-cutting changes. From the last 3 months, this seems to happen once or twice a month. We have a bit over 100 commits/day, so that seems fine.
  • By default all backends get linked, so all binaries get larger by the size of the AVR backend (but people who care probably already have an explicit list of enabled targets)

Mixed:

  • The AVR backend will likely grow more users, which might expose bugs :slight_smile:

From an outsider’s perspective (mine), the AVR backend seems in better shape than some non-experimental targets.

What do you see as the pros and cons of making it a stable target? Does anyone else have any concerns about doing so?

My only concern with AVR is having active mantainers. It doesn't seem
to have had much development in the last 6 months.

-Tom

What do you see as the pros and cons of making it a stable target? Does anyone else have any concerns about doing so?

My only concern with AVR is having active mantainers. It doesn’t seem
to have had much development in the last 6 months.

https://reviews.llvm.org/p/dylanmckay/ looks reasonably active to me. And it looks a lot more active than e.g. XCore :slight_smile:

Hi,

There was a thread a few days ago about the expectations for experimental targets. At the moment, the only experimental target is AVR. It's been in the tree for a long time now, and generally seems well-behaved.

FYI, the VE target is also experimental at this point.

- Simon

Should we just make it a normal target?

Nico

Should we just make it a normal target?

My only remaining reservation here - the generic DebugInfo tests, which presumably due to an unimplemented 16-bit branch somewhere deep in the llvm-objdump callstack.

The AVR backend passes virtually all of the LLVM test suite but these when avr-unknown-unknown is set as the default target. It feels like the inclusion of ~80 XFAILs for these DebugInfo tests would be the only wart on the experimental->official code review. I’ve had a couple long attempts debugging this one, but have not yet found the source.

Fixing of the DebugInfo tests would make the AVR official backend pitch much more tenable.

My only concern with AVR is having active mantainers. It doesn’t seem
to have had much development in the last 6 months.

This is a fair assessment; throughout the years, the amount of code I as the code owner directly write definitely follows something like a sine wave, with the last few months being one of the slower periods due to work and other personal projects. I value others’ thoughts on this topic stronger than my own though, so I will reserve judgement.

Compared to say, the ARM backend, the AVR backend has much less corporate backing or resourcing, essentially developed by enthusiasts and those interested in electronics in their spare time. The arguments for and against making either backend official or not may or may not be different - I am not sure what the community thinks.

As of the two months or so, there’s been quite a number of patches from both driveby and newly-active contributors. I suspect at least part of this will be due to the official deprecation of GCC’s AVR backend[1] and impending removal from the tree. As far as I know, this will make LLVM the only open-source AVR C/C++ toolchain in active development, and perhaps more importantly, supporting of newer language standards.

In summary, if the DebugInfo tests were fixed, I think the AVR backend would be ready to be marked official. I am also interested in any other thoughts people have about the AVR backend.

Regards,
Dylan

A recent patch <https://reviews.llvm.org/D73911&gt; indicated there were
issues to be solved still with disassembly. Although I know we don't
have hard and fast rules here, it feels to me like it would be worth
resolving those issues prior to flipping the switch on the basis that
a working disassembler is something most people would expect from a
"supported" backend that implements the MC layer.

Best,

Alex

Should we just make it a normal target?

My only remaining reservation here - the generic DebugInfo tests, which presumably due to an unimplemented 16-bit branch somewhere deep in the llvm-objdump callstack.

Would that be fixed with this patch? It makes llvm-objdump work for me and allows debugging with avr-gdb.
Can you perhaps point me to the tests that are failing?
https://reviews.llvm.org/D74213

(Re-sending because my previous mail was sent from the wrong address, sorry for the duplicates).

I don’t see why this would be a blocker. It’s not like everything is perfectly functional on all targets

-Matt

ARC is another experimental target Nico forgot to mention in
https://lists.llvm.org/pipermail/llvm-dev/2020-February/139158.html .

What is its status?

Hello,

We have an internal bot to make sure it keeps building and passing tests.
We have only had to make a couple of minor changes to fix breakages that weren't noticed and fixed by others first.

Pete

Would that be fixed with this patch? It makes llvm-objdump work for me and allows debugging with avr-gdb.

Can you perhaps point me to the tests that are failing?

I re-ran the test suite with ‘-DLLVM_TARGET_ARCH=avr-unknown-unknown’ and now the only errors I get are JIT errors related to no JIT compiler enabled for my host machine, x86. It seems the few failing generic CodeGen tests have since been fixed, along with the ~80 or so DebugInfo tests no doubt fixed by one of Ayke’s recent changes.

I’ve also opened up a patch to make AVR an official backend: https://reviews.llvm.org/D75099. All comments welcome.

Let’s move the discussion there.

  • Dylan

Parachuting here, collating many responses into one, forgive me.

Pros:
- LLVM's release binaries contain AVR support :slight_smile:
- It'd happen to remove the only backend that's currently marked experimental, which imho makes the build config easier to understand

I think well maintained and well behaved backends with real users (no
matter how many) should be built by default once they fulfilled their
experimental cooling period successfully.

Cons:
- Everyone gets to pay the cost for maintaining AVR for cross-cutting changes. From the last 3 months, this seems to happen once or twice a month. We have a bit over 100 commits/day, so that seems fine.
- By default all backends get linked, so all binaries get larger by the size of the AVR backend (but people who care probably already have an explicit list of enabled targets)

Those are the costs of every backend, and as they go, AVR seems pretty
cheap in comparison, so I don't see a problem here.

(Tom) My only concern with AVR is having active mantainers. It doesn't seem to have had much development in the last 6 months.

I agree this may be a sign of potential bit-rot, but as long as it has
real users and the maintainer is up for fixing the eventual bugs quick
enough, it's ok to have a slow paced back-end, especially without
heavy corporate backing.

For example:

(Dylan) I re-ran the test suite with '-DLLVM_TARGET_ARCH=avr-unknown-unknown' and now the only errors I get are JIT errors related to no JIT compiler enabled for my host machine, x86. It seems the few failing generic CodeGen tests have since been fixed, along with the ~80 or so DebugInfo tests no doubt fixed by one of Ayke's recent changes.

This looks like an active sub-community to me. The JIT "errors" are
not really errors. When we turned the ARM backend built by default it
had no JIT support at all either. Just mark them as ignored in LIT.

The buildbot (http://lab.llvm.org:8014/builders/llvm-avr-linux) is
green for quite a while, which is also positive.

--renato

To tie things together, Dylan’s change to move AVR out of experimental has landed :slight_smile: