search for: riscy

...; Value* which really points to Instruction*. There should also be some > mechanism to avoid creating two immediate operands, if target does not allow > that. 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 = dyn_cast<Constant>(I.getOperand(1))) { // handle add r, i } else { // handle general 'add r,r' case. } }...

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,

...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 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 :) Surely, optimization...

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 = dyn_cast<Constant>(I.getOperand(1))) { > // handle add r, i > } else { > // ha...

...move away from using the SUIF frontend, > but the backend works fine. Essentially, for right now, I have to convert > LLVM IR to SUIFvm IR. > > http://www.eecs.harvard.edu/hube/software/nci/suifvm.html > http://www.eecs.harvard.edu/hube/software/nci/overview.html Okay, it's a RISCy architecture of sorts. I don't see any documentation on the binary format. Does it require register allocation? If not, it might be easier to write the target in the style of the C-backend (which doesn't use any of the code generator components). If it does, making use of the code g...

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

...this is the case. The optimizer and code generator has logic (see SelectionDAG::ComputeNumSignBits) that propagates around the number of sign bits that a computation is known to have. This allows it to eliminate redundant sign extension instructions, and this is very important for common RISCy systems. Since the C ABI guarantees that "X" returns a sign extended value here, it is safe to assume it in callers, even if you can't see the implementation of the callee. > " > define i32 @bar() { > ; call > %tmp = call i32 @foo() > %x = trunc i32 %...

...UIF frontend, but the backend works fine. >> Essentially, for right now, I have to convert LLVM IR to SUIFvm IR. >> >> http://www.eecs.harvard.edu/hube/software/nci/suifvm.html >> http://www.eecs.harvard.edu/hube/software/nci/overview.html > > > Okay, it's a RISCy architecture of sorts. I don't see any documentation > on the binary format. Does it require register allocation? If not, it > might be easier to write the target in the style of the C-backend (which > doesn't use any of the code generator components). If it does, making &g...

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 >

...; > The optimizer and code generator has logic (see > SelectionDAG::ComputeNumSignBits) that propagates around the number of > sign bits that a computation is known to have. This allows it to > eliminate redundant sign extension instructions, and this is very > important for common RISCy systems. > > Since the C ABI guarantees that "X" returns a sign extended value > here, it is safe to assume it in callers, even if you can't see the > implementation of the callee. > > > " > > define i32 @bar() { > > ; call > > %tmp...

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