search for: allusesavailableat

Displaying 4 results from an estimated 4 matches for "allusesavailableat".

2011 Nov 16
2
[LLVMdev] Possible Remat Bug
...... Yeah, no kidding! >> So if Reg is an allocatable physical register, it gets returned as an >> implicit use. This directly contradicts the comment when talks about >> virtual registers exclusively. >> >> So who's right here? > > You want LiveRangeEdit::allUsesAvailableAt() which performs the same > check today. But not in 3.0, right? > The important point is that all registers read by the rematerialized > instruction have the same value at the new site. That applies to both > physical and virtual registers. Yes, absolutely. I actually do this check...
2011 Nov 16
0
[LLVMdev] Possible Remat Bug
On Nov 16, 2011, at 10:23 AM, David A. Greene wrote: > Jakob Stoklund Olesen <stoklund at 2pi.dk> writes: >> You want LiveRangeEdit::allUsesAvailableAt() which performs the same >> check today. > > But not in 3.0, right? Yes, 3.0 defaults to RAGreedy which uses the new spilling framework. It is ignoring the -spiller=... command line option. Also note that SplitKit does cheap-as-a-copy rematerialization when splitting live ranges. B...
2011 Nov 16
0
[LLVMdev] Possible Remat Bug
...#ifndef NDEBUG > break; > #endif Scary... > So if Reg is an allocatable physical register, it gets returned as an > implicit use. This directly contradicts the comment when talks about > virtual registers exclusively. > > So who's right here? You want LiveRangeEdit::allUsesAvailableAt() which performs the same check today. The important point is that all registers read by the rematerialized instruction have the same value at the new site. That applies to both physical and virtual registers. There is some ambiguity about instructions reading reserved registers. For example, we...
2011 Nov 16
2
[LLVMdev] Possible Remat Bug
I'm working on some enhancements to rematerialization that I hope to contribute. It's mostly working but I am running into one problem. It boils down to having spilled a register used by the remat candidate. I thought this is what getReMatImplicitUse is supposed to handle but it looks inconsistent to me. The comment says this: /// getReMatImplicitUse - If the remat definition MI has