llvm dev - Feb 2020 - Moving the AVR backend out of experimental

>
> 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

- [1] https://gcc.gnu.org/ml/gcc-patches/2019-09/msg01256.html



On Mon, Feb 17, 2020 at 9:57 PM Simon Moll via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> On 2/14/20 4:59 PM, Nico Weber via llvm-dev wrote:
>
>
> 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
>
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://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/20200218/f47d52f1/attachment.html>

On Tue, 18 Feb 2020 at 07:45, Dylan McKay via llvm-dev
<llvm-dev at lists.llvm.org> wrote:
>>
>> 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.
A recent patch <https://reviews.llvm.org/D73911> 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).

Ayke
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20200218/c42f2128/attachment.html>

> On Feb 18, 2020, at 02:44, Dylan McKay via llvm-dev <llvm-dev at
lists.llvm.org> wrote:
> 
> Fixing of the DebugInfo tests would make the AVR official backend pitch
much more tenable.
> 
I don’t see why this would be a blocker. It’s not like everything is perfectly
functional on all targets

-Matt
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20200218/5cdfde4b/attachment.html>

> 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


On Wed, Feb 19, 2020 at 5:05 AM Matt Arsenault <arsenm2 at gmail.com>
wrote:
>
>
> On Feb 18, 2020, at 02:44, Dylan McKay via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
>
> Fixing of the DebugInfo tests would make the AVR official backend pitch
> much more tenable.
>
>
> I don’t see why this would be a blocker. It’s not like everything is
> perfectly functional on all targets
>
> -Matt
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20200225/5c4cbe64/attachment.html>