search for: implicitdef

On Oct 20, 2012, at 3:37 PM, Vincent Lejeune <vljn at ovi.com> wrote: > #5 0x00000000010c8e83 in (anonymous namespace)::JoinVals::getAssignments (this=0x7fffffffd230) at RegisterCoalescer.cpp:1305 Does this fix it? diff --git a/lib/CodeGen/RegisterCoalescer.cpp b/lib/CodeGen/RegisterCoalescer.cpp index ba6b456..2ca67d6 100644 --- a/lib/CodeGen/RegisterCoalescer.cpp +++

...______ > De : Jakob Stoklund Olesen <stoklund at 2pi.dk> >À : Vincent Lejeune <vljn at ovi.com> >Cc : "llvmdev at cs.uiuc.edu" <llvmdev at cs.uiuc.edu> >Envoyé le : Dimanche 21 octobre 2012 0h05 >Objet : Re: [LLVMdev] RegisterCoalescing pass crashes with ImplicitDef registers > > > > >On Oct 20, 2012, at 1:23 PM, Vincent Lejeune <vljn at ovi.com> wrote: > >below is an output of "llc -march=r600 -mcpu=cayman -print-before-all -debug-only=regalloc file.shader" command from llvm3.2svn. >>The register coalescing pass cra...

On Oct 20, 2012, at 1:23 PM, Vincent Lejeune <vljn at ovi.com> wrote: > below is an output of "llc -march=r600 -mcpu=cayman -print-before-all -debug-only=regalloc file.shader" command from llvm3.2svn. > The register coalescing pass crashes when joining vreg12:sel_z with vreg13 registers, because it tries to access the interval liveness of vreg13... which is undefined. >

....e. data that needs to be touched by the dynamic linker even though it's ultimately read-only, and data that cannot be shared between multiple processes using LLVM. It turns out that a solid ~1.3MB of that data is in the tablegen'd MCInstrDesc tables - there a pointers for ImplicitUses, ImplicitDefs, and OpInfo that need to be relocated. This can be fixed of course by having target-global arrays for those structures referenced by MCInstrInfo (and hence TargetInstrInfo), and only storing offsets into those global arrays in MCInstrDesc. The downside is that several relevant accessors need...

...dynamic linker even though it's >> ultimately read-only, and data that cannot be shared between multiple >> processes using LLVM. >> >> It turns out that a solid ~1.3MB of that data is in the tablegen'd >> MCInstrDesc tables - there a pointers for ImplicitUses, ImplicitDefs, and >> OpInfo that need to be relocated. >> >> This can be fixed of course by having target-global arrays for those >> structures referenced by MCInstrInfo (and hence TargetInstrInfo), and only >> storing offsets into those global arrays in MCInstrDesc. >> >...

...ting register classes. > > I tend to think the second would be preferable, but how would we handle > registers than can hold different types of values? AFAIK, the type inference is only a convenience, you can always use explicit casts to get at the other types. It's the use of HasOneImplicitDefWithKnownVT() that scares me, I don't think there is any workaround for that. /jakob /// HasOneImplicitDefWithKnownVT - If the instruction has at least one /// implicit def and it has a known VT, return the VT, otherwise return /// MVT::Other. MVT::SimpleValueType CodeGenInstruction:: HasOneI...

...sure how to get the information I need at the IR level. I need to iterate over all operands of an instruction, analyzing each operand to get a register number (if available), see if the operand is a register or an immediate, get the operand def, and some other stuff. I also need to be able to do implicitDef/Use determination on instructions. I don't see a way to do this at present. So, any guidance would be much appreciated. Thanks! Griffin Wright

...while attempting to pick a node to schedule, we're running out of candidates (in ScheduleDAGRRList::PickNodeToScheduleBottomUp). This causes us to try to copy a node, and in the process, we call getPhysicalRegisterVT. This function asserts that the MCInstrDesc associated with the node will have ImplicitDefs, but in our case, it does not. In short: does this seem to be a problem of missing information in the MCInstrDesc, or should we not have arrived at that assert in the first place? Thanks, - Elliot -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.l...

Jakob Stoklund Olesen <stoklund at 2pi.dk> writes: > It appears that tablegen is inferring the 'type' of an individual > register by enumerating all the register classes it appears in. Some > things, like using implicit defs in SDNodes, only works for registers > with a unique type. My WIDE32 class caused GR32 registers to no > longer have a unique type, breaking

...le, but how would we handle >> registers than can hold different types of values? > > AFAIK, the type inference is only a convenience, you can always use > explicit casts to get at the other types. True. Wouldn't that also work for implicit defs? > It's the use of HasOneImplicitDefWithKnownVT() that scares me, I don't > think there is any workaround for that. Can you explain more? I'm not quiet following. What workaround is needed? Are you saying that in the current system it's broken because it relies on a single type for a register or that replacing it wi...

So I tried adding a new register class to the x86 target: def WIDE32 : RegisterClass<"X86", [i32, f32], 32, (add GR32, FR32)>; I thought this would be a harmless thing to do since the new register class is not being referenced anywhere. I was wrong, it caused all kinds of assertion failures from tablegen's isel pattern generator. It appears that tablegen is inferring the

...> a node to schedule, we're running out of candidates (in > ScheduleDAGRRList::PickNodeToScheduleBottomUp). This causes us to try to > copy a node, and in the process, we call getPhysicalRegisterVT. This > function asserts that the MCInstrDesc associated with the node will have > ImplicitDefs, but in our case, it does not. > > In short: does this seem to be a problem of missing information in the > MCInstrDesc, or should we not have arrived at that assert in the first > place? > > Thanks, > > - Elliot > > > > _________________________________________...

...information I need at the IR level. > I need to iterate over all operands of an instruction, analyzing each > operand to get a register number (if available), see if the operand is a > register or an immediate, get the operand def, and some other stuff. I > also need to be able to do implicitDef/Use determination on instructions. > I don't see a way to do this at present. If your pass really needs to analyze the use of physical registers and whether individual machine instructions are using immediate operands or not, then it needs to stay at the machine level. If you only really...

...ule, we're running out of candidates (in > > ScheduleDAGRRList::PickNodeToScheduleBottomUp). This causes us to try to > > copy a node, and in the process, we call getPhysicalRegisterVT. This > > function asserts that the MCInstrDesc associated with the node will have > > ImplicitDefs, but in our case, it does not. > > > > In short: does this seem to be a problem of missing information in the > > MCInstrDesc, or should we not have arrived at that assert in the first > > place? > > > > Thanks, > > > > - Elliot > > > > &...

Hi, below is an output of "llc -march=r600 -mcpu=cayman -print-before-all -debug-only=regalloc file.shader" command from llvm3.2svn. The register coalescing pass crashes when joining vreg12:sel_z with vreg13 registers, because it tries to access the interval liveness of vreg13... which is undefined. I don't know if it's a bug of the pass, or if my backend should do something

...t;; llvm-dev at lists.llvm.org <llvm-dev at lists.llvm.org> Subject: Re: [llvm-dev] Nested instruction patterns rejected by GlobalISel when having registers in Defs The implicit defs don't participate much in the patterns. For the most part it's just read into CodeGenInstruction::ImplicitDefs and then GlobalISel gathers and adds them all at the end. I think I do see the code Gabriel is referring to though. GetNumNodeResults() has: if (InstInfo.HasOneImplicitDefWithKnownVT(CDP.getTargetInfo()) !=MVT::Other) ++NumDefsToAdd; and ultimately this VT gets into Types via UpdateN...