similar to: virtual subregister liveness?

On Fri, 2019-08-30 at 10:03 -0700, Quentin Colombet wrote: > > On Aug 30, 2019, at 8:31 AM, Jesper Antonsson via llvm-dev < > > llvm-dev at lists.llvm.org> wrote: > > > > Hi, > > > > After dead-mi-elimination I'm experiencing a machine verifier > > failure > > at this virtual subregister write: > > > > %5.sub1 = COPY undef

On 05/16/2017 11:57 AM, Daniel Sanders wrote: >> If that's right, one possible fix would be to rename some of the subregister indices but that's likely to be quite painful. I'll have a think and see if I can come up with something nicer. > > I haven't been able to come up with a better answer for this, just an alternate choice as to where the complexity is. If we were

Hi, I'm stuck trying to fix a variety of problems that occur with undef subregisters 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:

Hi Tom, The output: Added VReg_64(explicit) Added VS_32(explicit (VS_32) VReg_64 class-with-subregs: VReg_64) is saying that VS_32 was added because VReg_64 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

Yes, the arch is just as you said, something like AMD GPU, but Intel GPU don't have separate register file for 'scalar/vector'. In fact my idea of defining the register tuples was borrowed from SIRegisterInfo.td in AMD GPU. But seems that AMD GPU mainly support i32/i64 register type, while Intel GPU also support byte/short register type. So I have to start defining the registers from

I'm running into a problem with subregs during trivial coalescing in the linear scan allocator. Should RALinScan::attemptTrivialCoalescing be allowed 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

On 5/16/2013 11:17 AM, Jakob Stoklund Olesen wrote: > > Would this TRI function solve your problem? >[...] > /// > /// Covering = getCoveringLanes(); > /// MaskA = getSubRegIndexLaneMask(SubA); > /// MaskB = getSubRegIndexLaneMask(SubB); > /// > /// If (MaskA & ~(MaskB & Covering)) == 0, then SubA is completely covered by > /// SubB.

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

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

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, I'm with a team using 16-bit bytes for an out-of-tree target. The AsmPrinter framework's implementation of the DWARF debugging format is not very good at distinguishing between target-sized bytes (which is the more common use) and 8-bit-bytes. The DWARF standard itself seems not very good in this regard, actually. So we have had to hack our way around this. I.e., at some call-sites of

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#

A. This RFC outlines a proposal regarding non-8-bit-byte support that got positive reception at a Round Table at EuroLLVM19. The general topic has been brought up several times before and one good overview can be found in a FOSDEM 2017 presentation by Jones and Cook: https://archive.fosdem.org/2017/schedule/event/llvm_16_bit/ In a nutshell, the proposal is for the llvm community

On Thu, 2019-05-02 at 19:54 +0200, Pavel Šnobl wrote: > Hi Jesper, > > thank you for working on this. My company (Codasip) would definitely > be interested in having this feature upstream. I think that this is > actually important for a suprisingly large number of people who > currently have to maintain their changes downstream. I have a couple > of questions and comments:

*From: *JF Bastien via llvm-dev <llvm-dev at lists.llvm.org> *Date: *Thu, May 9, 2019 at 1:30 PM *To: *Jesper Antonsson *Cc: *dag at cray.com, llvm-dev at lists.llvm.org I don’t think you have consensus to move forward at this point in time. My > expectation, which I think represents LLVM’s historical approach, is that a > path to full support be planned out before this effort starts.

Hi, I'm a bit unsure of the semantics of undef physical registers. The explanations I've seen in the code and in the langref seems to pertain more to constant values and virtual registers. What I really want to achieve is a push-pop of a register to have a temporary to work with, without having to check if this register is defined or not. However, whenever the reg is not defined before

On Wed, 2019-05-08 at 11:12 -0700, Philip Reames wrote: > On 5/8/19 1:25 AM, Jesper Antonsson wrote: > > On Mon, 2019-05-06 at 15:56 -0700, Philip Reames via llvm-dev > > wrote: > > > On 5/6/19 2:43 AM, Tim Northover via llvm-dev wrote: > > > > On Mon, 6 May 2019 at 10:13, James Courtier-Dutton via llvm-dev > > > > <llvm-dev at lists.llvm.org>

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

Hi Quentin, Let me clarify if I understood this correctly. If the accesses (writes and reads) to sub-registers are expressed always as sub-registers of the super-register register class (e.g., SuperReg.sub1;), then the spilling decision is for the super register. But, if the accesses are in terms of the register class of the sub-registers directly (SubReg;), then the spilling decision will