similar to: LLVM tool-chain for RISC-V

I am using LLVM version 4.0.1 Running `llc -march=riscv64 math.ll` returns: #0 0x0000000000fed7d1 (llc+0xfed7d1) #1 0x0000000000fec559 (llc+0xfec559) #2 0x0000000000fec8d9 (llc+0xfec8d9) #3 0x00007f22c044e5e0 __restore_rt (/lib64/libpthread.so.0+0xf5e0) #4 0x0000000000d7faf3 (llc+0xd7faf3) #5 0x0000000000cd4b88 (llc+0xcd4b88) #6 0x0000000000cd530c (llc+0xcd530c) #7 0x00000000006858c3

I tried to build LLVM to include the RISCV (experimental) target. I noticed that the instructions on the wiki were out of dat because they said to use '-DLLVM_TARGETS_TO_BUILD', but this gave a warning to use `LLVM_EXPERIMENTAL_TARGETS_TO_BUILD` as well (or instead?). So I compiled with these options: cmake -DCMAKE_BUILD_TYPE=MinSizeRel -DCMAKE_C_COMPILER=gcc >

Hi Devs, since risc-v has a register $tp which is thread pointer. is it possible to have __builtin_thread_pointer for RISC-V? I am not sure what could be corresponding instructions? ./kamlesh

I'm working on writing a backend for a processor that only has one Branch instruction, a BRnzp, where it branches on a status register (NZP: Negative, Zero, Positive) based on what the result of the last arithmetic operation was. It's implicitly set, nowhere in userspace. Basically, it follows the format of: ADD .... BR 010 ... (Branches if the result of the ADD was zero). Unconditional

For background on these calls, see <http://lists.llvm.org/pipermail/llvm-dev/2019-September/135087.html>. Reminder: the purpose is to co-ordinate between active contributors. If you have support questions etc then it's best to post to llvm-dev. We have a call every alternate Thursday at 4pm BST, via <https://meet.google.com/ske-zcog-spp>. We have created a shared calendar which

For background on these calls, see <http://lists.llvm.org/pipermail/llvm-dev/2019-September/135087.html>. Reminder: the purpose is to co-ordinate between active contributors. If you have support questions etc then it's best to post to llvm-dev. We have a call every alternate Thursday at 4pm GMT, via <https://meet.google.com/ske-zcog-spp>. We have a shared calendar which may help

I am using llvm-project compiling risc-v programs. llvm-project version:dd8a2013dc1804be1b7d9cffacad2e984300bd22 Instructons to build LLVM+clang: ``` cmake -G Ninja -DCMAKE_INSTALL_PREFIX=/home/llvm/workspace/llvm/llvm-project/llvm_install -DCMAKE_BUILD_TYPE="Release" -DDEFAULT_SYSROOT="/home/llvm/workspace/riscv/riscv-tc-20200220/bin/riscv32-unknown-elf"

Hello, I am working on the assembly printer for RISC-V, more specifically on the AsmPrinter class. I altered the RISCV Backend to print C code instead of Assembly, interpreted by libraries... (but that's not important) My problem is that, for my application to work, I need to treat my functions in the order they are in the original C file. I discovered that these functions are not treated

http://llvm.org/doxygen/namespacellvm_1_1Intrinsic.html#a441f366e90feb68d310546c271bcd31e I noticed that there are a lot of intrinsice in `include/llvm/IR/Intrinsics*.td` that reference GCCBultIn, and looking at the functions they're referencing it seems to be based on things already built into GCC. Why is it done this way instead of just building them from scratch (or importing the

On 18 August 2016 at 00:08, Renato Golin <renato.golin at linaro.org> wrote: > On 17 August 2016 at 10:14, Alex Bradbury via llvm-dev >> * Codegen >> * Compressed instruction set support (RVC) >> * Benchmarking and comparison to GCC RISC-V (and potentially other archs) > > What about buildbots? > > I'm assuming "check-all" would be enough for

I built llvm + clang from source, a github clone from today: clang version 11.0.0 (https://github.com/llvm/llvm-project.git 91aa67bf290bc7f877b1b90128284863bc31aa43) I compiled a small program: #include <stdint.h> int main() { uint8_t a = 2; uint8_t b = 5; uint8_t c = a * b; } $ clang -c -target riscv32 -march=rv32imc -g main.c Works fine. The dumped assembly seems to not know

Things like this in `lib/Target/ARM/ARMExpandPseudoInsts.cpp` FunctionPass *llvm::createARMExpandPseudoPass() { > return new ARMExpandPseudo(); > } And other functions have basically the same style. What's the point of doing it this way instead of just calling `new ARMExpandPseudo` in any place that you would have called this function? -- Ahmed Samara M.S. Computer Engineering

On Wed, 22 Jan 2020 at 19:55, Chris Lattner via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > On Jan 21, 2020, at 5:00 AM, Alex Bradbury <asb at lowrisc.org> wrote: > >> This all makes sense to me. > > > > That's correct, thanks for the feedback. > > > > I do like the idea from James of having the compiler always spit out a > > note

On Tue, 21 Jan 2020 at 01:14, Chris Lattner <clattner at nondot.org> wrote: > > On Jan 16, 2020, at 10:01 AM, Alex Bradbury via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > I believe code should be committed to LLVM when it is of sufficient > > quality, when it can be shown to benefit the LLVM user or developer > > communities, and when there is someone

Hi Everyone, I am wondering how to use RISC-V V (Vector) extension instructions in LLVM IR. In 2019 Kruppe and Espasa gave a talk [1] overviewing the Vector extension and on slide 16 [2] they show LLVM IR samples which use the vector instructions through intrinsic functions, such as: %vl = call i32 @llvm.riscv.vsetvl(i32 %n) At the time of the talk (April 2019) LLVM support for the V

There will be a RISC-V focused Birds of a Feather (BoF) session at the LLVM Dev Meeting in a few weeks time <https://2017llvmdevmtg.sched.com/event/CMiv/co-ordinating-risc-v-development-in-llvm> (Wednesday, October 18, 4:20pm - 5:05pm) The aim of this session is to bring together everyone with an interest in RISC-V support LLVM, and especially those from companies who have had private

As you will have seen from previous postings, I've been working on upstream LLVM support for the RISC-V instruction set architecture. The initial RFC <http://lists.llvm.org/pipermail/llvm-dev/2016-August/103748.html> provides a good overview of my approach. Thanks to funding from a third party, I've recently been able to return to this effort as my main focus. Now feels like a good

Hello, I'm using rsync on RISC-V machines. I notice that the developers of rsync seem to assume that only x86 CPUs can handle memory misalignments: ```c /* We know that the x86 can handle misalignment and has the same ?* byte order (LSB-first) as the 32-bit numbers we transmit. */ #if defined __i386__ || defined __i486__ || defined __i586__ || defined __i686__ || __amd64 #define

On 21 March 2018 at 20:07, Alex Bradbury <asb at lowrisc.org> wrote: > On 23 November 2017 at 09:38, Alex Bradbury <asb at lowrisc.org> wrote: >> On 14 November 2017 at 16:03, Alex Bradbury <asb at lowrisc.org> wrote: >>> Dear list, >>> >>> At the RISC-V BoF at the LLVM Dev Meeting and the longer working >>> session the day after,

--- src/filearch.c | 21 +++++++++++++++------ 1 file changed, 15 insertions(+), 6 deletions(-) diff --git a/src/filearch.c b/src/filearch.c index 5985b73..cbc8372 100644 --- a/src/filearch.c +++ b/src/filearch.c @@ -56,14 +56,16 @@ cleanup_magic_t_free (void *ptr) # endif COMPILE_REGEXP (re_file_elf, - "ELF.*(MSB|LSB).*(?:executable|shared object|relocatable),