similar to: A question about "make check-all"

Hello, I have successfully build the newest llvm from git source, and I would like to do some experiments on target AVR. Does "make check-all" cover AVR? All I need some extra steps to test AVR? I have neither AVR simulator nor real AVR board connected. Thank you. -------------- next part -------------- An HTML attachment was scrubbed... URL:

Say, I have the following program:    #include <iostream>    int main(){      std::cout << "hello\n";      return 0;    } After generating llvm bitcode using the following command:       $ clang++ -c -emit-llvm -O -Xclang -disable-llvm-passes a.cpp the bitcode has the following function with define. __cxx_global_var_init    main   

Hi, The AVRDevice.td of the AVR target seems too old, some devices like at90s have already been End-Of-Live, and some devices such as AVR DA family are not included. It is possible to make this TD file follow current microchips device list definition ? I am glad to take this work. 1. remove EOL devices 2. add new production devices Ben -------------- next part -------------- An HTML

Thank you for both of your input. Yes, I try to cross-compile for AVR, the simple ATMEGA328P used in every Arduino Uno. My main motivation being that I hope to be able to use a couple of STL containers, <functional> and <type_traits> on the MCU. Not sure though if this can be reached by going via the clang route. Getting back to the compilation: when I run clang with both both

Hi everyone, I've been wondering how to correctly build clang/LLVM for the AVR target architecture. Unfortunately documentation is very scarce (or outdated or I didn't find it) and while I've been able to build clang/LLVM for AVR I'm still falling short of compiling an actual binary for the MCU. Here are the steps I've undertaken so far: git clone

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

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.

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

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

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

> 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

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

I think this is broken in at least one place when legalising the DAG. This llvm ir: %3 = call { i16, i1 } @llvm.umul.with.overflow.i16(i16 %2, i16 11) Fails to lower correctly on AVR but the problem is, unfortunately, not just coming from the AVR Target code and I am not sure it can be cleanly fixed just there. (But I would be very happy to be proved wrong as I'm very new to this.) The above

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

Hi, I recently started helping with the LLVM AVR backend [1]. The AVR is an 8 bit core with pointer type i16. That makes pointers illegal in the SelectionDAG. As far as I understand it, it is the backends job to legalize these nodes by using the ReplaceNodeResults/LowerOperation callbacks. Is that about right? I have the feeling that the symbolic nodes carrying pointers, like FrameIndex are

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

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

Hi Leslie, On 20 December 2017 at 10:51, Leslie Zhai via llvm-dev <llvm-dev at lists.llvm.org> wrote: > Sorry, I am apprentice of lowRISC, and meet new bug when porting GlobalISel > to RISCV target > https://github.com/xiangzhai/llvm/commit/b3f91ea54d9fee0ef7e73a32c6b8456bbe252811 > > > In file included from >

I am working on an LLVM backend for the AVR architecture, and am having troubles working with the codegen layer, trying to get around the quirks of the binary encodings of the AVR ISR. There are several different families of AVR microcontrollers, each with a minimum 'core' instruction set. Each family builds upon (or removes) the core ISR with more instructions or different encodings. My

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