similar to: Build status expectations for experimental targets

> On Feb 3, 2017, at 4:18 AM, Tobias Grosser via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > On Fri, Feb 3, 2017, at 11:37 AM, Dylan McKay via llvm-dev wrote: >> Hey all, >> >> Every few weeks, a change is committed to trunk that breaks the AVR >> buildbot. >> >> A problem presents when commit authors do not fix the build, and just

> On Feb 3, 2017, at 12:45 PM, Dylan McKay via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > The builder isn’t marked as experimental so I think the expectation is that people keep it green and contact the bot owner if they need help figuring out why their change makes it red. That said, it sounds a bit odd to have a non-experimental builder for an experimental backend. >

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

Hey all, The AVR backend has now finally been merged in-tree completely. Thanks to Krzysztof and Matt for all of their hard work reviewing patches <https://reviews.llvm.org/differential/query/AuHaJ3SXjDmO> Development will now halt on the downstream repository (on GitHub <https://github.com/avr-llvm/llvm>), and it will now be done LLVM proper. This is good news, especially for the

Is there anything I can do about it? BTW: gcc is loosing the AVR backend, so I would assume, there will be a greater interest to this in llvm compared to the past. Thanks, Wilhelm Am 03.04.20 um 15:09 schrieb Wilhelm Meier via llvm-dev: > Should I create an issue in bugzilla for this? Just to be reminded ... > > Am 31.03.20 um 09:34 schrieb Wilhelm Meier via llvm-dev: >> Hi

Hey Wilhelm, That's a bug, the "interrupt" attribute is not being recognized by the backend. I have fixed it in https://github.com/llvm/llvm-project/commit/339b34266c1b54a9b5ff2f83cfb1da9cd8c9d90a Pull the latest LLVM and it should be fixed. On Tue, Mar 31, 2020 at 8:00 AM Wilhelm Meier <wilhelm.meier at hs-kl.de> wrote: > Hi Dylan, > > I used the following

Hi Dylan, looks ok now. One thing: the ISR is now: __vector_21: ; @__vector_21 __vector_21$local: sei push r0 push r1 in r0, 63 push r0 clr r0 push r24 lds r24, v1 sts v2, r24 pop r24 pop r0 out 63, r0 pop r1 pop r0 reti There are unneccessary push/pops of r1 and r0 too, since the clr is useless ... GCC had the same

Hey Wilhelm, Could you post the LLVM IR generated from your C++ file? This can be achieved with 'clang -S -emit-llvm' Cheers On Sat, Mar 28, 2020 at 6:36 PM Wilhelm Meier <wilhelm.meier at hs-kl.de> wrote: > Answering partly to myself there was a extern "C" missing. > > But the register pushes ans reti are still missing. > > Whats wrong? > > Am

Hi Dylan, the following code volatile uint8_t v1; volatile uint8_t v2; __attribute__((interrupt)) void __vector_21(void) { v2 = v1; } produces in C mode: 00000092 <__vector_21>: 92: 80 91 61 00 lds r24, 0x0061 ; 0x800061 <v1> 96: 80 93 60 00 sts 0x0060, r24 ; 0x800060 <__data_end> 9a: 08 95 ret and in C++ mode: 00000074

Am 04.03.20 um 13:28 schrieb Dylan McKay: > > * *The C/C++ function needs to be declared with either the calling > convention avr-interrupt or avr-non-blocking-interrupt.* Skipping > this step will cause regular ret instructions to be emitted for > return-from-subroutine, instead of the required reti for interrupt > handlers. ISRs also have stricter

Thanks! The new are of xmega3 architecture, which is already included. So this should be simple. Where is the information about ISR-vector table, SRAM addresses and so on stored? -- Wilhelm Am 04.03.20 um 11:03 schrieb Dylan McKay: > Hey Wilhelm, > > This should be possible by editing the 'AVRDevices.td' [1]TableGen > definitions to add an entry for the newer chip types.

I maintain and develop an AVR backend for LLVM on GitHub <https://github.com/avr-llvm/llvm>. It has now progressed quite far, with the ability to compile most non-trivial programs unmodified (for example, the Arduino <https://www.arduino.cc/> suite. It has complete machine code/ELF support, also implementing the entire instruction set (as of 2015), and a functionally-complete assembly

Am 04.03.20 um 11:16 schrieb Dylan McKay: > > The new are of xmega3 architecture, which is already included. So this > should be simple. > > Where is the information about ISR-vector table, SRAM addresses and so > on stored? > > > At the moment, this is not implemented in LLVM; these details are left > to the frontend. Clang/compiler-rt does not

To those interested in AVR backend additions to LLVM, the LLVM review tools "Phabricator" ( don't ask me to say that 3 times fast ), allows easy searching. Go to http://reviews.llvm.org/ and type in AVR in the search entry. This will give you a list of the commits, and resolutions. From my understanding ( NO Expert ), a large part of the skeleton code has been added. The leave

How is the llvm-avr backend integration going ? Will it be functional ( experimental ) in the 3.8 release ? Will Clang recognize options for avr ? thanks. Allen -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20151218/be23dc42/attachment.html>

On Jul 15, 2009, at 4:48 PMPDT, Daniel Dunbar wrote: > That depends on what you call a false positive. The public buildbot > regularly fails because of mailing Frontend tests, and I have had > continues failures of some DejaGNU tests for a long time on some > builders. Its not a false positive per se, but one starts to ignore > the failures because they aren't unexpected. Yes.

Exciting!!! > On Sep 29, 2015, at 17:03 , Hal Finkel via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > ----- Original Message ----- >> From: "Dylan McKay via llvm-dev" <llvm-dev at lists.llvm.org> >> To: llvm-dev at lists.llvm.org, "David Siegel" <agnat at me.com> >> Sent: Thursday, September 3, 2015 10:35:16 PM >>

2009/7/15 Dale Johannesen <dalej at apple.com> > > On Jul 15, 2009, at 4:48 PMPDT, Daniel Dunbar wrote: > > > That depends on what you call a false positive. The public buildbot > > regularly fails because of mailing Frontend tests, and I have had > > continues failures of some DejaGNU tests for a long time on some > > builders. Its not a false positive per

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:

Hello all, I have submitted and merged patches for most of the public modifications required for the AVR backend, and I am amount to start the process of adding the lib/Target/AVR directory piece by piece. As this will be a significant portion of code (~7000 lines), it should have a code owner. I have been working on the backend for the last year, maintaining it, overseeing contributions, and