similar to: Build Clang/LLVM for AVR

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

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

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

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, I’ve come back and updated my llvm toolset with modern code (my branch was about 1-2 years old) and now the llvm IR files produced by my front end no longer compile with llc. Here is a sample of llvm ir produced by my front end (it’s a standard version 3.1 build of swift from the swift.org open source website). ; ModuleID = 'main.ll' source_filename = "main.ll" target

That’s useful info, thanks. I think it will be useful for me to understand the connection, why this type of pointer is being emitted now. Do you have any suggestions where i can look to find the platform specific code that is making function pointers go into addrspace? Carl p.s. I am also working on passing the avr target flag to swift, but swift itself had (has?) limitations that make it

Trunk clang does not pass CMake C Compiler test like below: CMake Error at /home/usr4/c74014i/opt/cmake-3.16.3-Linux-x86_64/share/cmake-3.16/Modules/CMakeTestCCompiler.cmake:60 (message): The C compiler "/home/usr4/c74014i/opt/clang/current/bin/clang" is not able to compile a simple test program. It fails with the following output: Change Dir:

Hello Leslie, I think we are going to need to know a bit more about the ELF ABI for what looks like the ArcCompact before we can help you. LLD's calculation of P (the place to be relocated) is as it is in the generic ELF specification. The Rel.Offset corresponds to the ELF r_offset field. This is covered by: "For a relocatable file, the value is the byte offset from the beginning of the

Cool. That explains a lot! Sorry if this is a total n00b question, but… how does the datalayout string get overridden? in llvm/lib/Target/AVR/AVRTargetMachine.cpp I can see the code that determines the default datalayout for AVR… static const char *AVRDataLayout = "e-P1-p:16:8-i8:8-i16:8-i32:8-i64:8-f32:8-f64:8-n8-a:8”; However in the LLVM iR below, the target datalayout was present and

Hi Pete, Thanks for your kind response! I migrated AVR target for lld https://reviews.llvm.org/D32991 it is very beginning, only support R_AVR_CALL reloc, and ARC is more complex than AVR, I will learn it from binutils, also ARC related doc, then try to implement it. 发自我的iPhone ------------------ Original ------------------ From: Pete Couperus <Peter.J.Couperus at synopsys.com> Date:

Hi Martin, > The CPU that I am targeting is VLIW with no hardware interlocking (the next instruction does not wait for the previous to complete). This leads to fairly complex scheduling, but can be generally accommodated well in LLVM. Thanks for sharing your usecase about instruction scheduling, I am learning Instruction Selector by reading ARM and AMDGPU target's source code, then

Hi Pete, > https://reviews.llvm.org/D36331 Congratulations! > Following shortly: > * Clang driver and target triple support. great, then it is able to generate ELF by $ /opt/llvm-svn/bin/clang -c --target=arc hello.c -o hello.o -mmcu=XXX and do you plan to implement ARC target for lld[1]? it is a good testcase: flash them directly to the chip[2], or simulator[3]. 1. ARC

When I compile this LLVM IR…. @0 = private constant [19 x i8] c"V4main10Brightness\00", section "__TEXT,__swift3_typeref, regular, no_dead_strip" @1 = private constant [9 x i8] c"Vs5UInt8\00", section "__TEXT,__swift3_typeref, regular, no_dead_strip" @2 = private constant [18 x i8] c"currentBrightness\00", section "__TEXT,__swift3_reflstr,

Hi, I have a case that for pointer with address space attribute, pointer arithmetic is not work. For example, -bash-4.4$ cat test.c #define __user __attribute__((address_space(1))) void __user * test(void __user *arg) { #ifdef ADD return arg + 4; #else return arg; #endif } -bash-4.4$ -bash-4.4$ clang -g -c test.c -bash-4.4$ clang -g -c -DADD test.c clang-10: ../lib/IR/Instructions.cpp:2749:

Hello I've been looking at a debuginfo issue on an out-of-tree target which uses DWARF aranges. The problem is that aranges are generated for both data and code objects, and the debugger gets confused when program addresses overlap data addresses. The target is a Harvard Architecture CPU, so the appearance of overlapping address ranges is not in itself a bug as they reside in different

I forgot the -DADD flag earlier but the result did not change: https://godbolt.org/z/NPcn22 ________________________________________ From: llvm-dev <llvm-dev-bounces at lists.llvm.org> on behalf of Doerfert, Johannes via llvm-dev <llvm-dev at lists.llvm.org> Sent: Wednesday, October 30, 2019 20:18 To: LLVM Developers Mailing List; Y Song Cc: Alexei Starovoitov Subject: Re: [llvm-dev]

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 for the detailed info! The problem was that I tried without assertions and didn't inspect the IR closely as it contained this, for now, illegal instruction: %6 = bitcast i8* %5 to i8 addrspace(1)* This is clearly a clang error. I suggest opening a bug report, or sending the reproducer to cfe-dev at llvm.lists.org so someone will take a look that has more clang experience. @Matt Do

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: