search for: sub0

...ed to coalesce a COPY that uses a subreg as a destination? I've got the following sequence of code (unfortunately for an out of tree target) that is moving 32 and 64 bit sub-registers around within a 128 bit register. By the time the register allocator runs the code looks like: 92L %reg16402:dsub0<def> = DEF64.. %reg16402<imp-def>, QPR:%reg16402.... 116L %reg16405:sub0<def> = COPY %reg16402:sub1, %reg16405<imp-def>; QPR:%reg16405,16402 124L %reg16413:sub0<def> = COPY %reg16405:sub0<kill>; QPR:%reg16413,16405 .... stuff .... 468L %reg16460:sub3<def>...

...ing the class-with-subregs rule or not. This would allow us to prevent it from following the subreg indices into the wrong classes but it would also make it harder to define the register banks. > I'm a little confused about what the issue is. AMDGPU has 2 64-bit register classes each with sub0 and sub1 sub-registers: VReg_64:sub0=VGPR_32 VReg_64:sub1=VGPR_32 SReg_64:sub0=SGPR_32 SReg_64:sub1=SGPR_32 Are you saying that tablegen considers VReg_64:sub0 and SReg_64:sub0 to be the same sub-register class because they are both called sub0 ? -Tom >> On 10 May 2017, at 21:58, Daniel...

...al subregister write: %5.sub1 = COPY undef %11 The machine verifier essentially complains that the rest of the register is undefined (a subregister write implies a "read" of the other parts). So the problem is that dead-mi-elimination has removed the previously existing defines of %5.sub0. Yet I'm unsure where the actual fault lies and I can't seem to find any documentation or list email that explains the modeling in detail. A few ideas: Are there some restrictions on where dead-mi-elimination can be run? (I'm working with an out-of-tree target and we've put this fa...

...ne verifier essentially complains that the rest of the > > register is undefined (a subregister write implies a "read" of the > > other parts). > > > > So the problem is that dead-mi-elimination has removed the > > previously > > existing defines of %5.sub0. Yet I'm unsure where the actual fault > > lies > > and I can't seem to find any documentation or list email that > > explains > > the modeling in detail. A few ideas: > > If %5 is used in full, %5.sub0 is supposed to be defined before that > use. > If %...

...ubRegIndexLaneMask(SubB); > /// > /// If (MaskA & ~(MaskB & Covering)) == 0, then SubA is completely covered by > /// SubB. > unsigned getCoveringLanes() const { return CoveringLanes; } Yes, this would solve my problem. I'm assuming that if I have subregisters Sub0..SubN (where Sub0 could be 0, i.e. the register itself), and corresponding masks Mask0..MaskN, and Mask0 & ~((Mask1|Mask2|..|MaskN) & Covering) == 0, this will imply that the subregisters Sub1..SubN cover Sub0. Thanks, -Krzysztof -- Qualcomm Innovation Center, Inc. is a member of Co...

...gFile = 0; } } // b-->byte w-->word d-->dword q-->qword // the set of uniform byte register def gpr_b : RegisterClass<"IntelGPU", [i8], 8, (sequence "Rb%u", 0, 4095)> { let AllocationPriority = 1; } def gpr_d : RegisterTuples<[sub0, sub1, sub2, sub3], [(add (decimate gpr_b, 4)), (add (decimate (shl gpr_b, 1), 4)), (add (decimate (shl gpr_b, 2), 4)), (add (decimate (shl gpr_b, 3), 4))]>; // simd byte u...

...was explicitly specified and that while inspecting VS_32, it noticed that every register in VS_32 was a subregister of a register from VReg_64 using a single common subregister index. I've added some more tracing to my local copy and it appears that the subregister index it found in common was sub0. On the next line, (not shown above) it also reports that they had sub1 in common too. I think the cause is that AMDGPU is re-using the same subregister index for unrelated registers and that tablegen assumes this means that they are compatible. If that's right, one possible fix would be to re...

...registers when the register coalescer eliminates identity copies. The fundamental problem is complexity from the fact that undef values are a special case since they don't have an associated VNInfo/Segment unless the value is used across blocks. For example, in this case, %0 has 2 subregisters sub0 and sub1: bb.0: undef %0.sub1:vreg_64 = COPY killed $vgpr0 bb.1: %0:vreg_64 = COPY %0 S_CBRANCH_EXECNZ %bb.1, implicit $exec bb.2: undef %0.sub1:vreg_64 = nofpexcept V_CEIL_F32_e32 killed %0.sub1, implicit $mode, implicit $exec S_BRANCH %bb.1 sub0 has no defined values...

On May 16, 2013, at 8:13 AM, Krzysztof Parzyszek <kparzysz at codeaurora.org> wrote: > The function TII::canCombineSubRegIndices has been gone for a while now, and I was wondering if there is a target-independent way of determining if a certain set of physical registers "adds up" to a larger register. For example, on X86, AL and AH together form AX. On Hexagon, R0 and R1 are

The function TII::canCombineSubRegIndices has been gone for a while now, and I was wondering if there is a target-independent way of determining if a certain set of physical registers "adds up" to a larger register. For example, on X86, AL and AH together form AX. On Hexagon, R0 and R1 are D0. The context here is an attempt to coalesce multiple loads/stores into fewer loads/stores

Hi Guys, I have a taget instruction which take a vec4 and returns a vec4.( say instruction “vec4:$dst mod( vec4:$src)" ) And I want to use it to match i an ir instruction/intrinsic function( say " float:$dst llvm.irmod( vec4:$src)" which takes a vec4, output a float. I think the procedure is: when I see the intrinsic llvm.irmod, I need to call "extractlt(

Hi Escha, Great to have your comment! Do you have any specific reason for not doing like this? I am not sure whether I understand your point correctly. For "just model one thread", do you mean "only considering ONE of the 8/16 working lanes that running in lock-step way"?? For my case, may be something like I only need to define r0~r127 as register for i32 register (each r#

...::Untyped. So something like this for ISD::STORE: SDValue ValueToBeStored = St.getOperand(…) auto SeqOps[] = { DAG.getTargetConstant(SP::IntPairRegClassID, MVT::i32), DAG.getNode(ISD::EXTRACT_ELEMENT, dl, MVT::i32, ValueToBeStored, DAG.getConstant(0, MVT::i32)), DAG.getTargetConstant(SP ::sub0, MVT::i32), DAG.getNode(ISD::EXTRACT_ELEMENT, dl, MVT::i32, ValueToBeStored, DAG.getConstant(1, MVT::i32)), DAG.getTargetConstant(SP ::sub1, MVT::i32) }; SDValue NewValueToBeStored = DAG.getMachineNode(TargetOpcode::REG_SEQUENCE, dl, MVT::Untyped, SeqOps); return DAG.getStore(…, NewValueToBeS...

...Timidity midi-player daemon # http://www.alsa-project.org/alsa-doc/alsa-lib/pcm_plugins.html ipc_key_add_uid false ipc_key 1025 ipc_perm 0660 ipc_gid audio # Don't put the rate here! Otherwise it resets the rate & channels set below, as shown by: cat /proc/asound/card0/pcm0p/sub0/hw_params slave { # 2 for stereo, 6 for surround51, 8 for surround71 channels 2 pcm { format S16_LE #format S32_LE #rate 44100 rate 48000 # http://www.alsa-project.org/alsa-doc/alsa-lib/pcm_plugins.html # Maybe helps nonblock true type hw card "...

Hi, I've run into an issue with the RegisterBankEmitter on the AMDGPU backend. AMDGPU has a register class: VS_32, which is non-allocatable and contains registers from both defined register banks (SGPRRegBank and VGPRRegBank). The RegisterBankEmitter is adding this class to the CoverageData array for both register classes, because it contains sub-registers of one of the classes explicitly

...ipc_key_add_uid false > > ipc_key 1025 > ipc_perm 0660 > ipc_gid audio > > # Don't put the rate here! Otherwise it resets the rate & > channels set below, as shown by: cat /proc/asound/card0/pcm0p/sub0/ > hw_params > slave { > # 2 for stereo, 6 for surround51, 8 for surround71 > channels 2 > pcm { > format S16_LE > #format S32...

...>> SDValue ValueToBeStored = St.getOperand(…) >> >> auto SeqOps[] = { >> DAG.getTargetConstant(SP::IntPairRegClassID, MVT::i32), >> DAG.getNode(ISD::EXTRACT_ELEMENT, dl, MVT::i32, ValueToBeStored, DAG.getConstant(0, MVT::i32)), >> DAG.getTargetConstant(SP ::sub0, MVT::i32), >> DAG.getNode(ISD::EXTRACT_ELEMENT, dl, MVT::i32, ValueToBeStored, DAG.getConstant(1, MVT::i32)), >> DAG.getTargetConstant(SP ::sub1, MVT::i32) >> }; >> >> SDValue NewValueToBeStored = DAG.getMachineNode(TargetOpcode::REG_SEQUENCE, dl, MVT::Untyped, Seq...

In http://reviews.llvm.org/D8713, I added the 64bit integer store ("std") and load ("ldd") instructions for 32bit sparc. But now I need codegen to know how to emit them, and am not sure the best way to go about teaching the backend that 64bit integers can be used natively, but only for loads and stores. (I originally wrote an earlier draft of question in the review but it

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