Nico Weber via llvm-dev
2020-Feb-14 15:58 UTC
[llvm-dev] 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200214/dfb6eb16/attachment.html>
Nico Weber via llvm-dev
2020-Feb-14 15:59 UTC
[llvm-dev] Moving the AVR backend out of experimental
+better dylanmckay address On Fri, Feb 14, 2020 at 10:58 AM Nico Weber <thakis at chromium.org> 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. > > Should we just make it a normal target? > > Nico >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200214/d34ec85d/attachment.html>
Chris Lattner via llvm-dev
2020-Feb-14 17:13 UTC
[llvm-dev] Moving the AVR backend out of experimental
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> On Feb 14, 2020, at 7:59 AM, Nico Weber via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > +better dylanmckay address > > On Fri, Feb 14, 2020 at 10:58 AM Nico Weber <thakis at chromium.org <mailto:thakis at chromium.org>> 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. > > 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/20200214/721c83dd/attachment.html>
Simon Moll via llvm-dev
2020-Feb-17 08:57 UTC
[llvm-dev] Moving the AVR backend out of experimental
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 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200217/42b1027c/attachment.html>
Dylan McKay via llvm-dev
2020-Feb-18 07:44 UTC
[llvm-dev] 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>
Possibly Parallel Threads
- Moving the AVR backend out of experimental
- [cfe-dev] Revisiting our informal policy to support two versions of MSVC
- Moving the AVR backend out of experimental
- Adding llvm-undname to the llvm-cov bot
- Ninja build (on Windows anyway) may be doing redundant work