search for: risci

On Mon, 7 Jun 2004, Vladimir Prus wrote: > > If you do this (which I recommend for the first step), you'll notice that > > it produces pretty horrible code, as all immediates are copied into > > registers before they are used. In other words, instead of getting: > > > > R2 = add R1, 17 > > > > You'll get: > > > > R3 = mov 17 >

Chris Lattner wrote: > > 1. The MachineInstrBuilder has methods to add register operand and > > immediate operand. However, what would be really nice is a method to add > > Value*. So, I would write: > > > > BuildMI(*BB, NM::add, 1).add(I.getOperand(0), I.getOperand(1)); > > > > and depending on whether the passed Value* is contant or instruction,

Hello, David > That's pretty optimistic, even for someone who knows what to do. It depends on the target. If it is pretty straightforward, than you can do almost all the stuff automatically. The estimate I provided was the real time for first working version for msp430 backend. If it is just 'normal' RISCy architecture and one should not care about ABI weirdness (this is usually

On Tuesday 24 November 2009 10:57, Anton Korobeynikov wrote: > If it is just 'normal' RISCy architecture and one should not care > about ABI weirdness (this is usually true for MCUs), then the estimate > is correct. You just provide patterns for all the operations, expand > everything unsupported. After that you need to write bunch of libcalls > and first version is ready

Chris Lattner wrote: > The ultimate solution is to use a pattern matching instruction selector > (which we are working on). In the meantime, depending on how RISCy your > target is, it's pretty easy to get reasonable code with few special cases. > Usually this is enough: > > ... visitAdd(Instruction &I) { > > if (ConstantInt *C =

On Tue, 18 Jan 2005, John Cortes wrote: >> Can you say a little bit about MACH-SUIF? With a brief google search, I >> didn't turn up anything that described the architecture. Is it a RISC-like >> machine with 32-bit instruction words? >> > > It's another VM representation. I haven't really gotten to know the nitty > gritty of the language so

On Monday 23 November 2009 09:01, Anton Korobeynikov wrote: > Hello > > > It is a RISC with around 60 instructions like a 80c51 instruction set > > (without mul/div) and with Direct or indirect memory acces. > > My estimate is something like a man-week for a person, who knows what to do > :) That's pretty optimistic, even for someone who knows what to do. The

On May 20, 2008, at 2:16 PM, <Alireza.Moshtaghi at microchip.com> <Alireza.Moshtaghi at microchip.com > wrote: > >> Ok, I'm not sure what issue you mean. Can you restate? > > I'm referring to your statement (below) where you say "there needs > to be > some attribute (or something) on foo". Ok. > What I don't understand is I >

Chris Lattner wrote: > On Tue, 18 Jan 2005, John Cortes wrote: > >>> Can you say a little bit about MACH-SUIF? With a brief google >>> search, I didn't turn up anything that described the architecture. >>> Is it a RISC-like machine with 32-bit instruction words? >>> >> >> It's another VM representation. I haven't really gotten

Chris Lattner wrote: > On Tue, 18 Jan 2005, John Cortes wrote: > >> Hi Chris, > > > Hi! I'm CC'ing the llvmdev list for the benefit of others. > >> Since I see you're very involved in LLVM, I need a little guidance on >> getting from C to MACH-SUIF. >> >> I've been given the task of using LLVM to translate C code to another

I have legit requirement to keep the switch generated lookup table in function section. The lookup table is being generated in SimplifyCFG pass and is treated as a global. Is there a good way to mark these lookup tables and recognize them later to keep them in function sections. --Sumanth -------------- next part -------------- An HTML attachment was scrubbed... URL:

>Ok, I'm not sure what issue you mean. Can you restate? I'm referring to your statement (below) where you say "there needs to be some attribute (or something) on foo". What I don't understand is I don't know who would be setting this attribute? Whatever you do, if you consider caller and callee are in different translation units, then all that we can know in the

On Mon, 19 May 2008 Alireza.Moshtaghi at microchip.com wrote: > Correction: > > The analysis I made regarding the callers knowledge of sign/zero > extension of return value is flawed. So I take it back. > > Never the less, I don't see how adding attributes would resolve this > problem either. Ok, I'm not sure what issue you mean. Can you restate? -Chris >

Chris, I see, so in deed the front-end sets the attributes on the declaration of the called function; which in theory is also available to the caller through the CALL node. Now here is what I think: I agree that 4 attributes are a bit ugly. I think we can only get away with 2 attributes to signify sign extension or zero extension. Currently the front end does not promote the function declaration;

On Tue, 18 Jan 2005, John Cortes wrote: > Hi Chris, Hi! I'm CC'ing the llvmdev list for the benefit of others. > Since I see you're very involved in LLVM, I need a little guidance on getting > from C to MACH-SUIF. > > I've been given the task of using LLVM to translate C code to another VM > architecture known as MACH-SUIF. For this architecture, i don't