search for: onsemi

The architecture that I'm targeting with an LLVM back end has SRA instructions for all its data sizes, but is missing SRL instructions for some data sizes. I'm having trouble with the SelectionDAGISel::ShrinkDemandedOps() pass. Although it runs after the DAG has been legalized, it replaces legal SRAs with illegal SRLs, which results in failures in instruction selection. Is there a

Have there been any developments in the codegen/scheduling infrastructure that would invalidate the advice given in this thread from September 2005? http://lists.cs.uiuc.edu/pipermail/llvmdev/2005-September/004798.html -Ken

Is there a simple way to override the target triple used in when running the generic codegen tests? I would expect that passing a value for TARGET_TRIPLE to make, as below, would do it but none of the tests appear to use the target_triplet variable generated in site.exp. > make TESTSUITE=CodeGen/Generic TARGET_TRIPLE=msp430-none-none check -Ken

On Wednesday, December 02, 2009 3:45 PM, Micah Villmow wrote: > > On Wednesday, December 02, 2009 12:33 PM, Ken Dyck wrote: > > > The main drawback of adding the new types is the extra > > burden it would > > put on back ends that don't use them, since they would need to add > > special lowering code for all the types they don't use. On > > the

On Wednesday, December 02, 2009 7:09 PM, Chris Lattner wrote: > > On Dec 2, 2009, at 12:32 PM, Ken Dyck wrote: > > > Would there be any interest/opposition to extending the set > of simple > > integer types in MVT to include the missing multiples of 8 > (up to 64 > > bits)? That is: i24, i40, i48, i56? > > > > Adding the types to MVT (and

When describing implicit register definitions for instructions in the InstrInfo.td file of a back end, what is the difference between using an 'implicit' node in the Pattern versus initializing the 'Defs' field? One difference seems to be that an 'implicit' node only comes into effect when the instruction is matched through the instruction's Pattern field. If the

On Wednesday, July 21, 2010 11:21 AM, Jakob Stoklund Olesen wrote: > > On Jul 21, 2010, at 7:44 AM, Ken Dyck wrote: > > Speaking of the rewriter, I've had some > problems recently where the > > rewriter replaces the last of the three > load instructions with a COPY > > instruction because isLoadFromStackSlot() > returns the same frame index > > for all

On Saturday, December 05, 2009 7:34 AM, Duncan Sands wrote, > > >> Would there be any interest/opposition to extending the > set of simple > >> integer types in MVT to include the missing multiples of 8 > (up to 64 > >> bits)? That is: i24, i40, i48, i56? > > By the way, the integer type legalization logic should > probably go like > this: let

Does anybody have any tips for generating spills/reloads for large non-vector registers? I'm working on a back end for a DSP architecture that has accumulator registers that are too large to be spilled or reloaded with a single instruction. All of their bits can be accessed in word-size chunks via three sub-registers (low, high, and ext). So loading or storing one requires three instructions:

On Tuesday, July 20, 2010 4:04 PM, Jakob Stoklund Olesen > > On Jul 20, 2010, at 10:57 AM, Ken Dyck wrote: > > > Does anybody have any tips for generating spills/reloads for large > > non-vector registers? > > [snip] > > > This is quite simple to handle. A register > MachineOperand has a subreg field for this > purpose. It is used to pick out subregisters

What guarantees, if any, does the scheduler make when two selection nodes are linked by a Flag type? Can I expect the machine instructions that are selected from the two nodes to be scheduled consecutively? I'm trying to implement code generation for SELECT_CC nodes in a back end that I'm working on. The compare operations on the architecture communicate via bits in a global status

I'd also like to register my disappointment that the slides and videos aren't available. On Friday, October 16, 2009 4:46 PM, David Greene wrote: > When I agreed to be a speaker, I signed off on having my > talk made publicly available. There does seem to be a > double-standard here and that's concerning. There are few things about this whole situation that aren't

Would there be any interest/opposition to extending the set of simple integer types in MVT to include the missing multiples of 8 (up to 64 bits)? That is: i24, i40, i48, i56? Adding the types to MVT (and ValueTypes.td) would allow LLVM to be targeted to architectures that have registers and operations of these sizes (for example, a 24-bit DSP that I'd like to develop a back end for has 24-,