similar to: [LLVMdev] VLIW Scheduling Redux

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

Hi, One of the long-standing code clean-up bugs in Bugzilla is to extract the Machine* code from the CodeGen library into a separate one, on which CodeGen depends ( http://llvm.org/bugs/show_bug.cgi?id=1121). I'd like to start working on this. The general approach I'm planning to take is: 1. Identify which code to move. 2. Eliminate all dependencies that the Machine code has on the

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

Two functions in DwarfDebug, addBlockByrefAddress() and addComplexAddress(), contain this snippet of code: // Decode the original location, and use that as the start of the byref // variable's location. const TargetRegisterInfo *RI = Asm->TM.getRegisterInfo(); unsigned Reg = RI->getDwarfRegNum(Location.getReg(), false); DIEBlock *Block = new (DIEValueAllocator) DIEBlock();

On Tue, Mar 8, 2011 at 5:14 AM, Jacques Van Damme <Jacques.VanDamme at synopsys.com> wrote: > I am writing a backend for an architecture that has only 16-bit word > addressing (No byte addresses ever.  All data are always 16-bit). > > How can I specify this in the backend? In short, you can't. Word-addressable memory is not currently supported in LLVM (or Clang, for that

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

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-,

Hi All, I am writing a backend for an architecture that has only 16-bit word addressing (No byte addresses ever. All data are always 16-bit). How can I specify this in the backend? As an example, consider the following instruction: %arrayidx = getelementptr [129 x i16]* @flags, i16 0, i16 %i.043 When I generate assembler code, this now results in %i.043 being multiplied by 2 in the address

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

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 Wed, Sep 11, 2013 at 12:29 AM, Andrew Trick <atrick at apple.com> wrote: > > If that is the goal, then you only want the modules for Machine IR, and maybe some core analysis passes. The “Machine” modules you listed above include machine code analysis or transform passes that you probably don’t want. Pruning the list to basic IR support: > >> - MachineBasicBlock >> -

VLIW (Very Long Instruction Word) is a long instruction format (called "group" hereafter) contains several instructions. These instructions are not dependent on each other and could be issued in a single cycle. At this moment there is no correspondent class for VLIW. MachineInstr object can only represent one instruction. Usually the number of instructions in a group is fixed. The

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 ValueTypes.td) would allow LLVM to be > targeted to architectures that have registers and operations of these > sizes

We have a two different dimensions for each instruction: slot assignments, and operand timings. These two are unrelated to each other, and also each (or both) can change for any given instruction from one architecture version to the next. The main concern for us was which of these mechanisms contains all the information that we need. We cannot express all the scheduling details by hand, and

Hi Krzysztof, 2018-02-08 13:32 GMT+08:00 Andrew Trick via llvm-dev < llvm-dev at lists.llvm.org>: > > > On Feb 4, 2018, at 9:15 AM, Yatsina, Marina via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > > Hi, > > What is the best way to model a scheduler for a VLIW in-order architecture? > I’ve looked at the Hexagon and R600 architectures and they are using

On Jan 18, 2011, at 7:01 AM, Ken Dyck wrote: > Should addBlockByrefAddress() and addComplexAddress() be doing the same? Yes. Can you prepare a patch ? Thanks, - Devang

Am 08.03.2011 um 19:59 schrieb Ken Dyck: > If you are interested, I can send you a patch of the changes that I > made to the 2.8 release for a backend that targets a 24-bit > word-addressable DSP, but it is quite rough and it includes changes in > which you probably aren't interested (support for non-power-of-2 > integer sizes and some other bug fixes). I would be interested

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? > > 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

In SelectionDAGBuilder::visitRet(), there is this bit of code: // FIXME: C calling convention requires the return type to be promoted // to at least 32-bit. But this is not necessary for non-C calling // conventions. The frontend should mark functions whose return values // require promoting with signext or zeroext attributes. if (ExtendKind !=

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 three load. For example, > > load a.l, <fi#n>, 0 load a.l, <fi#n>, 0 > load a.h