similar to: Custom Instruction Cost Model to LLVM RISC-V Backend

Thanks a lot Henrik! I figured following would mark a pointer to a specific address space: #define __myaddrspace __attribute__((address_space(1))) __myaddrspace int* data; And, I was able to verify loads being annotated to be from addrspace 1 in the generated IR. Would this work for automatic variables as well? In regards to using this in the backend, do I have to just modify the source, or

Hi, I am observing a strange behaviour in which Clang ignores __restirct when I include some standard headers. For example, this code: void vec_add(int* __restrict a, int* __restrict b, int n) { #pragma unroll 4 for(int i=0; i<n; ++i) { a[i] += b[i]; } } results in: ; Function Attrs: nofree norecurse nounwind define dso_local void @_Z7vec_addPiS_i(i32*

Hi, I'm trying to abstract some special pointers with a class, like in the example program below: 1 #define __remote __attribute__((address_space(1))) 2 #include <stdint.h> 3 4 __remote int* A; 5 __remote int* B; 6 7 class RemotePtr { 8 private: 9 __remote int* __restrict a; 10 11 public: 12 RemotePtr(__remote int* a) : a(a) {} 13 14 __remote

Hi Jeroen, Sorry, I missed that. I tried the patch, and this program: #include <stdint.h> #define __remote __attribute__((address_space(1))) __remote int* A; __remote int* B; void vec_add(__remote int* __restrict a, __remote int* __restrict b, int n) { #pragma unroll 4 for(int i=0; i<n; ++i) { a[i] += b[i]; } } int main(int argc, char** argv) {

Unfortunately https://llvm.org/docs/LangRef.html#llvm-loop-parallel-accesses-metadata is not a solution here. A loop-parallel access does not imply non-aliasing. The obvious case is when only reading from a location, but even when a location is written to I'd be careful to deduce that they do not alias since it might be a "benign data race" or the value never used. Additionally,

Hi Jeroen, That's great! I was trying to use the patch, what's the latest version of the project we could apply it on? Hi Neil, That seems like what I can do as well! Do you happen to have some examples lying around? Maybe a pointer to the planned presentation, if that's okay? Thank you, Bandhav On Mon, Jun 22, 2020 at 1:55 AM Neil Henning <neil.henning at unity3d.com>

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

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

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,

Hi Sjoerd, > Trying to remember how everything fits together here, but could > get.active.lane.mask not create the %mask of the VP intrinsics? Or in other > words, in the vectoriser, who's producing the %mask and %evl that is > consumed by the VP intrinsics? > > I'm not sure what would be the best way here. I think about the Loop Vectorizer. I imagine at some point we

Is there a full LLVM toolchain that can produce an object file runnable by spike (the risc-v ISA simulator)? I found some toolchains but from what I can tell, they still require that you invoke gcc to the assembly and linkage. Is there a reason llvm-as and lld haven't been ported or is it just because nobody has done it yet? -- Ahmed Samara PhD Student Computer Engineering --------------

On Wednesday, 14 September 2016 15:50:20 CEST Richard W.M. Jones wrote: > --- LGTM, just one question below. > + else if (strstr (elf_arch, "UCB RISC-V")) { > + ret = safe_asprintf (g, "riscv%s", bits); > + goto no_strdup; > + } Is this bit of output from `file` reliable at this point, or can it change in the future? I recall the RISC-V is a

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, those of us working on RISC-V with LLVM decided >> it would be worthwhile to schedule regular

On 08/17/2016 09:33 AM, James Y Knight via llvm-dev wrote: > > I haven't actually been following the story of the AVR backend at all, > but afaik the current status is that there's a partially completed AVR > backend in trunk that's been under construction for a year or so, and > a functional backend in another repository, which people actually use. > However that

On Wednesday, 14 September 2016 15:50:20 CEST Richard W.M. Jones wrote: > --- Ah, I forgot one thing: > + else if (strstr (elf_arch, "UCB RISC-V")) { > + ret = safe_asprintf (g, "riscv%s", bits); > + goto no_strdup; > + } I guess the "riscv16", "riscv32", and "riscv64" should be documented for the

Hi all, While compiling R to RISC-V64 architecture and debugging in R's C source codes, I think I have found a small bug. Can anyone please verify whether it is a real bug? The possible bug lies in the file `R-4.2.2/src/library/stats/src/approx.c` in function `R_approxfun` around line 148: #ifdef DEBUG_approx REprintf("R_approxfun(x,y, nxy = %.0f, .., nout = %.0f, method = %d,

Michael, Apologies for taking so long to get back to you. Trunk LLVM does not contain support for code generating the V extension yet. The experimental-v support you see there is only MC-layer support, where you can use the V instructions in assembly (including inline assembly). There is currently (today) no way of turning LLVM IR vector intrinsics into RISC-V V extension instructions. Hanna

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

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