similar to: [LLVMdev] On the transitivity of subregisterness

Hello. I come back to this older thread. As I've said before, I managed to patch the various files from the back end related to lanemask in order to support at most 1024 vector lanes. For this I am using a 1024-bit long lanemask of type uint1024_t from boost::multiprecision, instead of uint32_t. For this I changed the following LLVM source files:

You seem to be using old LLVM sources---changing this many files for supporting a different width LaneBitmask is no longer necessary. Also, boost is not a current requirement for building LLVM and it's unlikely that requiring it for that purpose alone is justified. -Krzysztof On 7/28/2017 6:30 AM, Alex Susu via llvm-dev wrote: > Hello. > I come back to this older thread.

Hello. I've managed to patch the various files from the back end related to lanemask - now I have 1024-bit long lanemask. But now I get the following error when giving make llc: <<error:unhandled vector type width in intrinsic!>> This error comes from this file https://github.com/llvm-mirror/llvm/blob/master/utils/TableGen/IntrinsicEmitter.cpp, comes from the

I'm working on the post-regalloc dataflow engine I mentioned yesterday. Currently I only need to track register operands. A MachineOperand has both a getReg() and a getSubReg() interface. For a physical register operand, is getReg() guaranteed to be the "most super" register with getSubReg() providing the specific subregister information for the operand? If so then for my current

On 4 October 2016 at 19:50, Krzysztof Parzyszek via llvm-dev <llvm-dev at lists.llvm.org> wrote: > If there are no objections, I'd like to start working on this soon... > > For the AMDGPU target this implies that RC->getSize will no longer be > available in the MC layer. Another advantage of this work that hasn't been mentioned yet is it will reduce the number of uses

On Apr 18, 2013, at 9:45 AM, dag at cray.com wrote: > I'm working on the post-regalloc dataflow engine I mentioned yesterday. > Currently I only need to track register operands. > > A MachineOperand has both a getReg() and a getSubReg() interface. For a > physical register operand, is getReg() guaranteed to be the "most super" > register with getSubReg()

Hello. In my TableGen back end description I need to use more than 32 (e.g., 128, 1024, etc) subregisters per register for my research SIMD processor. I have used so far with success 32 subregisters. However, when using 128 subregisters when I now give the command: llvm-tblgen -gen-register-info Connex.td I get an error message "error:Ran out of lanemask bits to

I've been working on patches to improve subregister liveness tracking on llvm and I wanted to inform the llvm community about the overal design/motivation for them. I will send the patches to llvm-commits later today. Greetings Matthias Braun Subregisters in llvm ==================== Some targets can access registers in different ways resulting in wider or narrower accesses. For

On Wednesday 23 January 2008 02:01, Evan Cheng wrote: > > Can you explain the basic mechanics of the live interval splitting > > code? > It's splitting live intervals that span multiple basic blocks. That > is, when an interval is spilled, it introduce a single reload per > basic block and retarget all the uses to use the result of the single > reload. It does not

Evan, Can you explain the basic mechanics of the live interval splitting code? Is it all in LiveIntervalAnalysis.cpp under addIntervalsForSpills and child routines? What is it trying to do? Also, in the ancient subregister coalescing code, there used to be an update of the SSARegMap to point subregisters to the superregister they were coalesced to (IIRC). That has since gone away. I used to

On Oct 8, 2013, at 2:06 PM, Akira Hatanaka <ahatanak at gmail.com> wrote: > What I didn't mention in r192119 is that mthi/lo clobbers the other sub-register only if the contents of hi and lo are produced by mult or other arithmetic instructions (div, madd, etc.) It doesn't have this side-effect if it is produced by another mthi/lo. So I don't think making mthi/lo clobber the

Currently it will always spill / restore the whole vreg but only spilling the parts that are actually live would be a nice addition in the future. Looking at r192119': if "mtlo" writes to $LO and sets $HI to an unpredictable value, then it should just have an additional (dead) def operand for $hi, shouldn't it? Greetings Matthias Am 10/8/13, 11:03 AM, schrieb Akira

What I didn't mention in r192119 is that mthi/lo clobbers the other sub-register only if the contents of hi and lo are produced by mult or other arithmetic instructions (div, madd, etc.) It doesn't have this side-effect if it is produced by another mthi/lo. So I don't think making mthi/lo clobber the other half would work. For example, this is an illegal sequence of instructions,

On Jan 22, 2008, at 12:23 PM, David Greene wrote: > Evan, > > Can you explain the basic mechanics of the live interval splitting > code? > Is it all in LiveIntervalAnalysis.cpp under addIntervalsForSpills > and child > routines? What is it trying to do? It's splitting live intervals that span multiple basic blocks. That is, when an interval is spilled, it

I am trying to locate a bug that affects my Blackfin backend. I am having some trouble understanding the semantics of def/kill flags on machine operands when using subregisters. I compile this function: define void @i56_ls(i56 %x) nounwind { store i56 %x, i56* @i56_s ret void } And get this initial machine code: Live Ins: %R0 %R1 %reg1025D<def> = MOVE %R1 %reg1024D<def> =

On Thu, 2008-10-02 at 11:19 -0700, Evan Cheng wrote: > > On Oct 2, 2008, at 11:02 AM, Sanjiv.Gupta at microchip.com wrote: > > > What’s the value produced by an INSERT_SUBREG node? Is it a chain? > > > No, insert_subreg returns a value: > > > v1 = insert_subreg v2, v3, idx > > > v1 and v2 will have the same type, e.g. i16, and v3 must have a >

Hi, I am trying to take 16 bit memory reads and combine them to a single 32 bit read. I am having trouble to make the code simply read 32 bytes and the use the subregisters accordingly, without unnecessary copying. I have tried two techniques, in the MachineFunction: 1. replace the MachineOperands in the users of the data with the new register/subregister index. This yields an assert failure

You need to specify sub-register == super-register, idx relationship. See X86RegisterInfo.td: def x86_subreg_8bit : PatLeaf<(i32 1)>; def x86_subreg_16bit : PatLeaf<(i32 2)>; def x86_subreg_32bit : PatLeaf<(i32 3)>; def : SubRegSet<1, [AX, CX, DX, BX, SP, BP, SI, DI, R8W, R9W, R10W, R11W, R12W, R13W, R14W, R15W], [AL, CL,

On Apr 16, 2013, at 10:27 AM, John Criswell <criswell at illinois.edu> wrote: > On 4/16/13 11:30 AM, dag at cray.com wrote: >> Is there a traditional dataflow algorithm buried in LLVM somewhere? I >> need to be able to do some very late transformations (after regalloc) >> and we aren't in SSA anymore. I will need a dataflow analysis to ensure >> correctness.

Andrew Trick <atrick at apple.com> writes: > David was asking for a post-register-rewrite analysis, which I think > is a totally different problem and best implemented separately by each > target. The target knows best which register units are overwritten or > preserved by an operation. We try to fake it with > undef/implicit-use/implicit-def, but it isn't reliable.