search for: implici

...PUs flag register: The scheduler has to respect the order! We are interested in liveness, but we do not necessarily want to spill/reload them or perform register allocation on a single register. - X87 floating point stack registers need special handling on top of the generic register allocation == Impliciations == Except for the register allocator not using them they behave like normal registers: - We track the liveness of unallocatable registers - The scheduler respects data/output dependencies for unallocatable registers == Examples == Assume r0 is a normal register, r1 is an unallocatable regist...

...duler has to respect the order! We are interested in liveness, but we do not necessarily want to spill/reload them or perform register allocation on a single register. >> - X87 floating point stack registers need special handling on top of the generic register allocation >> >> == Impliciations == >> Except for the register allocator not using them they behave like normal registers: >> - We track the liveness of unallocatable registers >> - The scheduler respects data/output dependencies for unallocatable registers >> >> == Examples == >> Assume...

...cator can never “reuse” them. More precisely, they are live out of the current frame, so reserved register writes can still be reordered with nearby instructions that *don’t* access that register. Dependencies still need to be tracked! I think copies could be optimized, but reserved registers are implicitly live out of the frame. Reserved register writes should not move across calls. See http://reviews.llvm.org/D15667. > == Motivation == > Generic backend code, especially register allocators make assumptions about how registers behave. These include things like the value in a register only c...

...er: The scheduler has to respect the order! We are interested in liveness, but we do not necessarily want to spill/reload them or perform register allocation on a single register. > - X87 floating point stack registers need special handling on top of the generic register allocation > > == Impliciations == > Except for the register allocator not using them they behave like normal registers: > - We track the liveness of unallocatable registers > - The scheduler respects data/output dependencies for unallocatable registers > > == Examples == > Assume r0 is a normal register,...

...respect the order! We are interested in liveness, but we do not necessarily want to spill/reload them or perform register allocation on a single register. >>> - X87 floating point stack registers need special handling on top of the generic register allocation >>> >>> == Impliciations == >>> Except for the register allocator not using them they behave like normal registers: >>> - We track the liveness of unallocatable registers >>> - The scheduler respects data/output dependencies for unallocatable registers >>> >>> == Examples...

...1] for a note on program counter/time stamp registers. == Implications == - We skip Liveness analysis because we know a reserved register is live anyway. - Register allocators cannot use a reserved registers: It is never free and therefore considered unallocatable. - Scheduling has to consider the implicit use on calls - No special considerations necessary for copy propagation - Writes to a reserved register are not dead code, because the value is always live out! == Examples == Assume r0 is a normal register r1 is a reserved register: - We can remove the 2nd COPY here: r0 = COPY r1 ... us...

On 02/25/2016 06:14 PM, Matthias Braun via llvm-dev wrote: > 1) The value read from a reserved register cannot be predicted. Reading a reserved register twice may each time produce a different result. This seems broken to me that treating another copy should be assumed to produce a different result. This seems like it should be optimized, and have a special volatile_copy instruction for the

...se” them. More precisely, they are live out of the current frame, so reserved register writes can still be reordered with nearby instructions that *don’t* access that register. > > Dependencies still need to be tracked! > > I think copies could be optimized, but reserved registers are implicitly live out of the frame. Reserved register writes should not move across calls. See http://reviews.llvm.org/D15667. Indeed the current code respects ordering dependencies for reserved registers, so rule 3) above can just be removed and we treat reserved regsiters like any other for reordering. We...

...ee how pc can fit this rule. > > == Implications == > - We skip Liveness analysis because we know a reserved register is live anyway. > - Register allocators cannot use a reserved registers: It is never free and therefore considered unallocatable. > - Scheduling has to consider the implicit use on calls > - No special considerations necessary for copy propagation Ditto for pc. > - Writes to a reserved register are not dead code, because the value is always live out! > > == Examples == > Assume r0 is a normal register r1 is a reserved register: > > - We can re...

...nter dereference xkb: Check if AddResource failed DRI2: Avoid call to NULL pointer Paulius Zaleckas (1): KDrive: Fix error handlig in tslib driver Peter Hutterer (94): dix: don't create core motion events for non-x/y valuators. xfree86: fix compiler warning about implicied decl of DuplicateModule. xfree86: rework driver PreInit API - XInput ABI 12 config: expose config_info as an input option. xfree86: make xf86ActivateDevice static. xfree86: remove superflous assignments. input: Purge Register*Device() functions. xfree86: purge...