Displaying 10 results from an estimated 10 matches for "instrsch".
Did you mean:
instrs
2005 Apr 22
0
[LLVMdev] tabs
...lib/Target/SparcV9/SparcV9RegClassInfo.h
Index: lib/Target/SparcV9/SparcV9RegInfo.cpp
Index: lib/Target/SparcV9/SparcV9RegInfo.h
Index: lib/Target/SparcV9/SparcV9SchedInfo.cpp
Index: lib/Target/SparcV9/SparcV9TargetMachine.cpp
Index: lib/Target/SparcV9/SparcV9TmpInstr.cpp
Index: lib/Target/SparcV9/InstrSched/InstrScheduling.cpp
Index: lib/Target/SparcV9/InstrSched/SchedGraph.cpp
Index: lib/Target/SparcV9/InstrSched/SchedGraph.h
Index: lib/Target/SparcV9/InstrSched/SchedGraphCommon.cpp
Index: lib/Target/SparcV9/InstrSched/SchedPriorities.cpp
Index: lib/Target/SparcV9/InstrSched/SchedPriorities.h
Index...
2005 Sep 27
1
[LLVMdev] How does the memory of MachineInstr objects are managed?
..., and
MachineInstr* are inserted back MachineBasicBlock in the scheduled
order.
The question is: isn't the memory of MachineInstr* "released/freed"
when it's removed from the MachineBasicBlock?
vector<MachineInstr*> S; // the schedule;
// reference implementation: SparcV9/InstrSched/InstructionScheduling.cpp
void recordSchedule(MachineBasicBlock &MBB) {
...
while (I != MBB.end())
MBB.remove(I++); // **** Q: Doesn't it invalidate the pointers in
'S' ?? ****
vector<MachineInstr*>::iterator I = S.begin(); S.end() != I; ++ I) {
MBB.push_back(...
2002 Nov 21
1
[LLVMdev] top of tree build failures
...ring directory `/scratch/scratch0/gaeke/llvm-497cz/lib/CodeGen/InstrSelection'
gmake[3]: Nothing to be done for `all'.
gmake[3]: Leaving directory `/scratch/scratch0/gaeke/llvm-497cz/lib/CodeGen/InstrSelection'
gmake[3]: Entering directory `/scratch/scratch0/gaeke/llvm-497cz/lib/CodeGen/InstrSched'
gmake[3]: Nothing to be done for `all'.
gmake[3]: Leaving directory `/scratch/scratch0/gaeke/llvm-497cz/lib/CodeGen/InstrSched'
gmake[3]: Entering directory `/scratch/scratch0/gaeke/llvm-497cz/lib/CodeGen/RegAlloc'
gmake[3]: Nothing to be done for `all'.
gmake[3]: Leaving dir...
2002 Nov 11
1
[LLVMdev] top of tree broken?
...ring directory `/scratch/scratch0/gaeke/llvm-497cz/lib/CodeGen/InstrSelection'
gmake[3]: Nothing to be done for `all'.
gmake[3]: Leaving directory `/scratch/scratch0/gaeke/llvm-497cz/lib/CodeGen/InstrSelection'
gmake[3]: Entering directory `/scratch/scratch0/gaeke/llvm-497cz/lib/CodeGen/InstrSched'
gmake[3]: Nothing to be done for `all'.
gmake[3]: Leaving directory `/scratch/scratch0/gaeke/llvm-497cz/lib/CodeGen/InstrSched'
gmake[3]: Entering directory `/scratch/scratch0/gaeke/llvm-497cz/lib/CodeGen/RegAlloc'
gmake[3]: Nothing to be done for `all'.
gmake[3]: Leaving dir...
2004 Jul 21
0
[LLVMdev] GC questions.
...IPA/Debug
? llvm/lib/Analysis/IPA/Depend
? llvm/lib/AsmParser/Debug
? llvm/lib/AsmParser/Depend
? llvm/lib/Bytecode/Reader/Debug
? llvm/lib/Bytecode/Reader/Depend
? llvm/lib/Bytecode/Writer/Debug
? llvm/lib/Bytecode/Writer/Depend
? llvm/lib/CodeGen/Debug
? llvm/lib/CodeGen/Depend
? llvm/lib/CodeGen/InstrSched/Debug
? llvm/lib/CodeGen/InstrSched/Depend
? llvm/lib/CodeGen/SelectionDAG/Debug
? llvm/lib/CodeGen/SelectionDAG/Depend
? llvm/lib/Debugger/Debug
? llvm/lib/Debugger/Depend
? llvm/lib/ExecutionEngine/Debug
? llvm/lib/ExecutionEngine/Depend
? llvm/lib/ExecutionEngine/Interpreter/Debug
? llvm/lib/E...
2004 Jul 21
2
[LLVMdev] GC questions.
On Wed, 21 Jul 2004, Tobias Nurmiranta wrote:
>
> Hi, I'm thinking out loud, please give me some feedback.
>
> Regarding llvm.gcread and llvm.gcwrite, wouldn't it be nicer if they are
> implemented as:
>
> llvm.gcread(sbyte** object, uint offset)
> llvm.gcwrite(sbyte* data, sbyte** object, uint offset)
>
> Where you also have the offset into the object. In
2004 Jul 21
0
[LLVMdev] GC questions.
Ok, that makes sense :).
, Tobias
On Wed, 21 Jul 2004, Chris Lattner wrote:
> On Wed, 21 Jul 2004, Tobias Nurmiranta wrote:
> > > void *llvm_gc_read(void *ObjPtr, void **FieldPtr) {
> > > return *FieldPtr;
> > > }
> >
> > Hm, but doesn't FieldPtr need to be calculated target-specific in those
> > cases?
>
> For the field pointer, one
2004 Jul 21
2
[LLVMdev] GC questions.
On Wed, 21 Jul 2004, Tobias Nurmiranta wrote:
> > void *llvm_gc_read(void *ObjPtr, void **FieldPtr) {
> > return *FieldPtr;
> > }
>
> Hm, but doesn't FieldPtr need to be calculated target-specific in those
> cases?
For the field pointer, one could use the getelementptr instruction:
%pairty = { sbyte, sbyte, int* }
%pairPtr = ...
%fieldptr = getelementptr
2004 Jul 22
2
[LLVMdev] GC questions.
...IPA/Debug
? llvm/lib/Analysis/IPA/Depend
? llvm/lib/AsmParser/Debug
? llvm/lib/AsmParser/Depend
? llvm/lib/Bytecode/Reader/Debug
? llvm/lib/Bytecode/Reader/Depend
? llvm/lib/Bytecode/Writer/Debug
? llvm/lib/Bytecode/Writer/Depend
? llvm/lib/CodeGen/Debug
? llvm/lib/CodeGen/Depend
? llvm/lib/CodeGen/InstrSched/Debug
? llvm/lib/CodeGen/InstrSched/Depend
? llvm/lib/CodeGen/SelectionDAG/Debug
? llvm/lib/CodeGen/SelectionDAG/Depend
? llvm/lib/Debugger/Debug
? llvm/lib/Debugger/Depend
? llvm/lib/ExecutionEngine/Debug
? llvm/lib/ExecutionEngine/Depend
? llvm/lib/ExecutionEngine/Interpreter/Debug
? llvm/lib/E...
2013 Oct 15
0
[LLVMdev] [llvm-commits] r192750 - Enable MI Sched for x86.
...unimplemented for AVX, so we may not be generating the best code yet.
>>
>> Unit tests are updated so they don't depend on SD scheduling heuristics.
>>
>> Modified:
>> llvm/trunk/lib/Target/X86/X86Subtarget.h
>> llvm/trunk/test/CodeGen/X86/2006-05-02-InstrSched1.ll
>> llvm/trunk/test/CodeGen/X86/2007-01-08-InstrSched.ll
>> llvm/trunk/test/CodeGen/X86/2009-02-26-MachineLICMBug.ll
>> llvm/trunk/test/CodeGen/X86/2010-02-19-TailCallRetAddrBug.ll
>> llvm/trunk/test/CodeGen/X86/2010-09-17-SideEffectsInChain.ll
>> l...