similar to: [LLVMdev] Dead register (was Re: [llvm-commits] [llvm] r145819)

Displaying 14 results from an estimated 14 matches similar to: "[LLVMdev] Dead register (was Re: [llvm-commits] [llvm] r145819)"

2011 Dec 05
0
[LLVMdev] Dead register (was Re: [llvm-commits] [llvm] r145819)
On Dec 5, 2011, at 12:56 PM, Hal Finkel wrote: > RegScavenger is complaining about use of an undefined register, CTR8, in > the BCTR8 instruction, in the following instance (this is from the PPC > backend): > > BB#38: derived from LLVM BB %for.end50 > Predecessors according to CFG: BB#36 > %X3<def> = LD 0, <fi#27>; mem:LD8[FixedStack27] >
2011 Dec 06
2
[LLVMdev] Dead register (was Re: [llvm-commits] [llvm] r145819)
On Mon, 2011-12-05 at 13:18 -0800, Jakob Stoklund Olesen wrote: > On Dec 5, 2011, at 12:56 PM, Hal Finkel wrote: > > > RegScavenger is complaining about use of an undefined register, CTR8, in > > the BCTR8 instruction, in the following instance (this is from the PPC > > backend): > > > > BB#38: derived from LLVM BB %for.end50 > > Predecessors
2012 Jun 08
0
[LLVMdev] Strong vs. default phi elimination and single-reg classes
On Jun 7, 2012, at 7:31 PM, Hal Finkel wrote: > 112B BB#1: derived from LLVM BB %for.body, ADDRESS TAKEN > Predecessors according to CFG: BB#0 BB#1 > %vreg12<def> = PHI %vreg13, <BB#1>, %vreg11, <BB#0>;CTRRC8:%vreg12,%vreg13,%vreg11 > %vreg13<def> = COPY %vreg12<kill>; CTRRC8:%vreg13,%vreg12 > %vreg13<def> = BDNZ8 %vreg13,
2012 Jun 08
2
[LLVMdev] Strong vs. default phi elimination and single-reg classes
Hello again, I am trying to implement an optimization pass for PowerPC such that simple loops use the special "counter register" (CTR) to track the induction variable. This is helpful because, in addition to reducing register pressure, there is a combined decrement-compare-and-branch instruction BZND (there are also other related instructions). I started this process by converting the
2012 Jun 08
2
[LLVMdev] Strong vs. default phi elimination and single-reg classes
On Thu, 7 Jun 2012 22:14:00 -0700 Jakob Stoklund Olesen <stoklund at 2pi.dk> wrote: > > On Jun 7, 2012, at 7:31 PM, Hal Finkel wrote: > > > 112B BB#1: derived from LLVM BB %for.body, ADDRESS TAKEN > > Predecessors according to CFG: BB#0 BB#1 > > %vreg12<def> = PHI %vreg13, <BB#1>, %vreg11, > >
2012 Jun 08
0
[LLVMdev] Strong vs. default phi elimination and single-reg classes
On Jun 7, 2012, at 10:54 PM, Hal Finkel wrote: > For example, sometimes LiveIntervals asserts with: > register: > %CTR8 > clang: /llvm-trunk/lib/CodeGen/LiveIntervalAnalysis.cpp:446: > void llvm::LiveInterval > s::handlePhysicalRegisterDef(llvm::MachineBasicBlock*, > llvm::MachineBasicBlock::iterator, llvm::SlotIndex, > llvm::MachineOperand&,
2012 Jun 08
2
[LLVMdev] Strong vs. default phi elimination and single-reg classes
On Fri, 8 Jun 2012 08:49:32 -0700 Jakob Stoklund Olesen <stoklund at 2pi.dk> wrote: > > On Jun 7, 2012, at 10:54 PM, Hal Finkel wrote: > > > For example, sometimes LiveIntervals asserts with: > > register: > > %CTR8 > > clang: /llvm-trunk/lib/CodeGen/LiveIntervalAnalysis.cpp:446: > > void llvm::LiveInterval > >
2012 Jun 08
0
[LLVMdev] Strong vs. default phi elimination and single-reg classes
On Jun 8, 2012, at 9:02 AM, Hal Finkel <hfinkel at anl.gov> wrote: > On Fri, 8 Jun 2012 08:49:32 -0700 > Jakob Stoklund Olesen <stoklund at 2pi.dk> wrote: >> When machine code is still in SSA form, there are restrictions on >> what can be done with physical registers, which by their nature can't >> be in SSA form. Lang and I have been trying to come up
2012 Jun 08
1
[LLVMdev] Strong vs. default phi elimination and single-reg classes
On Fri, 08 Jun 2012 09:24:16 -0700 Jakob Stoklund Olesen <stoklund at 2pi.dk> wrote: > > On Jun 8, 2012, at 9:02 AM, Hal Finkel <hfinkel at anl.gov> wrote: > > > On Fri, 8 Jun 2012 08:49:32 -0700 > > Jakob Stoklund Olesen <stoklund at 2pi.dk> wrote: > > >> When machine code is still in SSA form, there are restrictions on > >> what can
2016 Jul 29
2
Help with ISEL matching for an SDAG
I have the following selection DAG: SelectionDAG has 9 nodes: t0: ch = EntryToken t2: i64,ch = CopyFromReg t0, Register:i64 %vreg0 t16: i32,ch = load<LD1[%ptr](tbaa=<0x10023c9f448>), anyext from i8> t0, t2, undef:i64 t15: v16i8 = BUILD_VECTOR t16, t16, t16, t16, t16, t16, t16, t16, t16, t16, t16, t16, t16, t16, t16, t16 t11: ch,glue = CopyToReg t0, Register:v16i8 %V2, t15
2017 Oct 13
2
Machine Scheduler on Power PC: Latency Limit and Register Pressure
Hi, I've been looking at the Machine Scheduler on Power PC. I am looking only at the pre-RA machine scheduler and I am running it in the default bi-directional mode (so, both top down and bottom up queues are considered). I've come across an example where the scheduler picks a poor ordering for the instructions which results in very high register pressure which results in spills.
2018 Dec 07
2
Should intrinsics llvm.eh.sjlj.setjmp be with isBarrier flag?
Hi, I meet an issue when I verify machineinstrs for Powerpc testcases in llvm. llc -mtriple=powerpc64-unknown-linux-gnu < llvm/llvm/test/CodeGen/PowerPC/sj-ctr-loop.ll -verify-machineinstrs Bad machine code: MBB exits via unconditional fall-through but ends with a barrier instruction! *** function: main basic block: %bb.2 for.body.lr.ph (0x100275437e8) Content in block BB.2:
2017 Oct 13
3
Machine Scheduler on Power PC: Latency Limit and Register Pressure
> On Oct 13, 2017, at 1:46 PM, Matthias Braun <matze at braunis.de> wrote: > > Yes, I've run into the problem myself that the Pending queue isn't even checked with the tryCandidate() logic and so takes priority over all other scheduling decisions. > > I personally would be open to changes in this area. To start the brainstorming I could imagine that we move nodes
2008 Jun 30
4
Rebuild of kernel 2.6.9-67.0.20.EL failure
Hello list. I'm trying to rebuild the 2.6.9.67.0.20.EL kernel, but it fails even without modifications. How did I try it? Created a (non-root) build environment (not a mock ) Installed the kernel.scr.rpm and did a rpmbuild -ba --target=`uname -m` kernel-2.6.spec 2> prep-err.log | tee prep-out.log The build failed at the end: Processing files: kernel-xenU-devel-2.6.9-67.0.20.EL Checking