similar to: [LLVMdev] MOS6502 target

Well, the stack pointer be a single byte, so pushing things on there doesn't work terribly well. Assuming I pass by reference, that's 128 values absolutely total before it wraps around and silently clobbers itself. It means single byte values will be incredibly inefficient... Tricky stuff. I'm lucky on the C64 since it's rare to exit back to the kernel with machine language apps

I've mentioned my sneaky plans to target the MOS6502 here before. The big issue I think is that a lot of instructions don't really have a choice for output register. It all just goes into the accumulator, X index, or Y index based on the specific instruction. So, my question is, when I'm defining my ins, outs and registers for these instructions, is it going to be a problem that

I suppose that once you've got a 6502 working, adding support for a 4510 shouldn't be too difficult.... (http://c65gs.blogspot.com.au/) On Fri, Jul 4, 2014 at 10:38 AM, Bruce Hoult <bruce at hoult.org> wrote: > On Fri, Jul 4, 2014 at 12:02 PM, Edwin Amsler <edwinguy at gmail.com> wrote: > >> Well, the stack pointer be a single byte, so pushing things on there

On 7/13/2020 21:30, Thomas Lively via llvm-dev wrote: > Part of the problem is that ISel patterns are like their own DSL inside > the TableGen DSL, so keywords like "ins", "outs", and "ops" aren't > keywords at the TableGen level, but rather at the level of the ISel > system implemented with TableGen. Copying existing patterns and reading > the

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.

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

Hi, I am new to LLVM and I find TableGen language really cryptic. The reference manual to the language is not helpful either. I can look at the existing .td file and reverse engineer but I am looking for a detailed manual. Specifically, I have below questions: 1. What is a basic syntax for writing a dag? From the lang ref manual I can see that its something like operator followed by ArgList which

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?

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

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

Hi, I have a version of the old CBackend which is working with the current trunk. I am in the progress of rewriting it into a new version but that project is not going as fast as I would hope as I have been distracted by other tasks with higher priority lately. Anyway, for those interested, I can provide patches, optionally separated into several parts (core, testing, misc). I am afraid that

> 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