search for: implicitdefs

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

Here it is :  Starting program: /home/vlj/llvmbin/bin/llc -march=r600 -mcpu=cayman /home/vlj/shader [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib64/libthread_db.so.1". llc: /home/vlj/llvm/include/llvm/ADT/SmallVector.h:143: const T& llvm::SmallVectorTemplateCommon<T, <template-parameter-1-2> >::operator[](unsigned int) const [with T

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 t...

...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. >> >&...

...or 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:: HasOneImplicitDefWithKnownVT(const CodeGenTarget &TargetInfo) const { if (ImplicitDefs.empty()) return MVT::Other; // Check to see if the first implicit def has a resolvable type. Record *FirstImplicitDef = ImplicitDefs[0]; assert(FirstImplicitDef->isSubClassOf("Register")); const std::vector<MVT::SimpleValueType> &RegVTs = TargetInfo.getRegisterVT...

Hello all: I apologize for what I imagine is a rather silly question, but I'm still somewhat new to LLVM and am stuck. I am reworking some code that was originally in the backend involving MachineInstructions and MachineOperands, and I now need for it to function as an LLVM IR pass, using just Instructions, etc, and nothing related to 'Machine'. However, I am not sure how to get the

...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.ll...

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

...sOneImplicitDefWithKnownVT - 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:: > HasOneImplicitDefWithKnownVT(const CodeGenTarget &TargetInfo) const { > if (ImplicitDefs.empty()) return MVT::Other; > > // Check to see if the first implicit def has a resolvable type. > Record *FirstImplicitDef = ImplicitDefs[0]; > assert(FirstImplicitDef->isSubClassOf("Register")); > const std::vector<MVT::SimpleValueType> &RegVTs = >...

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 > > > > __________________________________________...

On Jun 2, 2011, at 9:46 AM, Griffin Wright wrote: > > Hello all: > > I apologize for what I imagine is a rather silly question, but I'm still > somewhat new to LLVM and am stuck. I am reworking some code that was > originally in the backend involving MachineInstructions and > MachineOperands, and I now need for it to function as an LLVM IR pass, > using just

...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 > > > > &g...

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 UpdateNo...