similar to: [LLVMdev] Python Backend

I'm very interested in this patch. Could you, Roel, upload it somewhere or maybe put your code to github or something simmilar? Additional - you're fixing it - could you please provide a little more information - what should I read to get more informations about writing not hardware but software backend in LLVM? (Of course the code analysis is one way, but maybe there is other also).

Hi! I'm trying to write LLVM Python Backend (to generate Python code out of LLVM IR) I'm still learning LLVM and for now it is very hard to me to even create simple taksk. I want you to ask 3 questions: ---------------------------------------------------------------------------------- 1) I want to base on some existing code to learn how it was build. I wanted to base on CBackend (which

Hello all, I am in need for a working C back-end for LLVM for my current research. I know that the previous incarnation of this back-end has been kicked out of the tree since the 3.1 release and I have gone through the archives to restore it to it's previous 'glory'. So far, I have restored most of the previous version (excluding some of the parts that needed changes outside of

I will take a look into NVPTX. I don't want to deconstruct C++ classes to generate Python code - I want to generate Python backend :) Its purpose is to be able to generate Python code from LLVM IR code (not C++ code! - C++ code is needed for me only to get a sample IR code). I want to write my custom compiler in the future and I want to be able to output Python code from it (of course not

I think the problem here is that the IR doesn't have any way to attach restrict information to loads/stores/pointers. It works on arguments because they can be given the 'noalias' attribute, and then the alias analyzer must understand what that means. Pete On Jan 24, 2012, at 7:47 AM, Roel Jordans wrote: > I have no clue, I didn't have time to look into that example yet.

hi, at the moment, TEST instruction is defined with 0xf7 opcode, as demonstrated below. $ echo "0xf7 0xc0 0x00 0x00 0x00 0x22"|./Release+Asserts/bin/llvm-mc -disassemble -arch=x86 .section __TEXT,__text,regular,pure_instructions testl $570425344, %eax ## imm = 0x22000000 however, i cannot find anywhere this F7 opcode is defined in

For those wondering about the C backend, a patch(set) to current trunk is available but too large to send through the LLVM mailinglist. I can send the patch(es) directly if people are interested. Cheers, Roel On 17/11/12 03:48, David Claughton wrote: > Hi Roel, > > On 13/09/12 11:02, Roel Jordans wrote: >> >> For those that are interested, I can provide a patch to the

On 17-03-17 22:34, Mehdi Amini wrote: >> On Mar 17, 2017, at 12:39 PM, Roel Jordans via llvm-dev <llvm-dev at lists.llvm.org> wrote: >> >> Hi all, >> >> I have a question related to GSoC. One of my students submitted an idea [1] for a GSoC project and I would be interested in (co-)mentoring this project but I'm unsure of the qualification requirements for

Can you explain please why it works for this version of the function: double f(double *__restrict__ x, double *__restrict__ y, double *__restrict__ z); What is different here? There are stores here as well. Brent On Wed, Jan 25, 2012 at 12:34 AM, Roel Jordans <r.jordans at tue.nl> wrote: > Hi Brent, > > I think this is a problem in the easy-cse transform. In this transform

If you want to get the original name by a library function, as Jonathan mentioned, you can call __cxa_demangle in cxxabi.h. However, this API is only available in gcc. If you want something more portable, try glog or libibert, notice libibert is GPL licensed. On Thu, Dec 11, 2014 at 7:57 AM, Roel Jordans <r.jordans at tue.nl> wrote: > When a C++ compiler translates source code it will

I have no clue, I didn't have time to look into that example yet. How does the IR (before optimization) differ from the other version? Roel On 01/24/2012 04:45 PM, Brent Walker wrote: > Can you explain please why it works for this version of the function: > > double f(double *__restrict__ x, double *__restrict__ y, double > *__restrict__ z); > > What is different here?

Hi all, I'm organizing a BoF session during the upcoming EuroLLVM developers meeting. As the subject of this message already shows, this session will be on compilers in education. I'm currently looking for both participants to the discussion and input for the actual program of the session. I've already got some ideas which I'll introduce below. At our university, we mostly

Peter Cooper wrote: > I think the problem here is that the IR doesn't have any way to attach restrict information to loads/stores/pointers. I think we do now, actually. Now that the loads and stores have TBAA metadata, I think the restrict attribute can go there. It needs to be attached to every use of a restrict pointer, but that's similar to how TBAA already works. > It works

> On Mar 18, 2017, at 4:56 PM, Eric Christopher <echristo at gmail.com> wrote: > > (Adding Anton here) > > On Fri, Mar 17, 2017 at 3:42 PM Roel Jordans via llvm-dev <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: > On 17-03-17 22:34, Mehdi Amini wrote: > >> On Mar 17, 2017, at 12:39 PM, Roel Jordans via llvm-dev <llvm-dev at

Hi Roel, the code you list below is precisely what I expect to get (of course the stores must happen but the constant folding should happen as well). It all looks very strange. LLVM is behaving as if the __restrict__ keyword was not used at all. Even more strange is the fact that for this function: double f(double *__restrict__ x, double *__restrict__ y, double *__restrict__ z) { *x = 1.0;

Hi Sergos and Samuel, Thanks for the links, I've got it mostly working now. I still have a problem with linking the code. It seems that the clang driver doesn't pass its library search path to nvlink when linking the generated cuda code to the target library, resulting in it not correctly finding libtarget-nvptx.a. Is there some flag or environment variable that I should set here?

On 13/09/12 10:57, Duncan Sands wrote: > Hi 조영필, > > > I want to manipulate LLVM-backend to emit other compiler's IR, in this case, >> VPO's IR. >> So, what i want to know is.. Is there a project to be referred? (For example, >> "Do LLVM-backend -> GIMPLE" project exist?) > > as far as I know there is no LLVM IR -> gimple pass. LLVM

----- Original Message ----- > From: "Roel Jordans" <r.jordans at tue.nl> > To: llvmdev at cs.uiuc.edu > Sent: Wednesday, August 13, 2014 5:57:15 AM > Subject: Re: [LLVMdev] Proposal for ""llvm.mem.vectorize.safelen" > > > > > WHY CURRENT METADATA DOES NOT SUFFICE > > ------------------------------------- > > > > There

Hello, See answers below On 31/01/13 00:23, César wrote: > Hello. > > I'm using these commands to compile the code below in order to collect > edge/blocks profiling: > > clang -emit-llvm -c sort.c -o sort.bc > opt -insert-edge-profiling sort.bc -o sort_prof.bc > clang sort_prof.bc -lprofile_rt -L/llvms/lib -o sort_prof > > then I run the program and display the

Hi Brent, I think this is a problem in the easy-cse transform. In this transform load operations can be replaced by their subexpression, in this case the propagated constant, based on the value of the 'CurrentGeneration' of memory writes. This implies that any store operation invalidates the knowledge about previously stored subexpressions. In general, this is a safe assumption but