[llvm-dev] RFC: Adding bit to register MachineOperands to allow post-RA register renaming
Hal Finkel via llvm-dev
llvm-dev at lists.llvm.org
Thu Oct 26 11:47:50 PDT 2017
On 10/26/2017 12:52 PM, Matthias Braun via llvm-dev wrote:
> I like the idea, this is not the first time we try to perform
> recoloring/renaming operations late. I agree with Quentin though that
> we should have a way to mark def and use operands! You can probably
> play more games and re-use the IsDead bit on use operands.
>
>> On Oct 26, 2017, at 5:54 AM, Nemanja Ivanovic via llvm-dev
>> <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote:
>>
>> Forgive me if these questions are naive or if I'm misunderstanding
>> something. I'm certainly very interested in seeing the
>> MachineCopyPropagation patch finally land and stick.
>>
>> 1. Wouldn't function live-ins and reserved registers have started
>> life as physical registers already? For example, wouldn't a live-in
>> be a copy from a physical register to a virtual one allowing the flag
>> to be set correctly on the def? A reserved register on the other hand
>> just seems like something we shouldn't touch, doesn't it?
>> 2. I must admit that I don't really know how Aggressive Anti
>> Dependence Breaker works, but doesn't it already rename registers?
>> How does it know which ones are safe to rename and which aren't?
> Heuristics which seem to work today but which at least I am not very
> comfortable with.
+1
It would be nice to replace this with a less fragile approach. We
already have number of instructions marked with hasExtraSrcRegAllocReq
and/or hasExtraDefRegAllocReq, and this seems like a more-precise,
dynamic, version of that.
I don't recall this being mentioned, but I imagine we'll also, in many
cases, want to mark registers returned by the scavenger marked as
eligible for renaming.
-Hal
> I think it's mostly this part:
>
> // If MI's defs have a special allocation requirement, don't allow
> // any def registers to be changed. Also assume all registers
> // defined in a call must not be changed (ABI). Inline assembly may
> // reference either system calls or the register directly. Skip it
> until we
> // can tell user specified registers from compiler-specified.
> if (MI.isCall() || MI.hasExtraDefRegAllocReq() ||
> TII->isPredicated(MI) ||
> MI.isInlineAsm()) {
> DEBUG(if (State->GetGroup(Reg) != 0) dbgs() << "->g0(alloc-req)");
> State->UnionGroups(Reg, 0);
> }
>
> - Matthias
>
>>
>> On Wed, Oct 25, 2017 at 10:20 PM, Quentin Colombet via llvm-dev
>> <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote:
>>
>> Hi Geoff,
>>
>> The principle sounds reasonable but it raises the question of
>> proper APIs to query that. E.g., when I am looking at a use, how
>> would we know that this is okay to rename? In other words, what
>> API do we provide for such use cases.
>>
>> Also, what do we do with registers that don’t have definition?
>> For instance, a function live-ins register, a reserved register,
>> and so on.
>>
>> Cheers,
>> -Quentin
>>
>> > On Oct 25, 2017, at 10:27 AM, Geoff Berry
>> <gberry at codeaurora.org <mailto:gberry at codeaurora.org>> wrote:
>> >
>> > Hi All,
>> >
>> > Currently, changing register assignments of definitions after
>> register allocation is not safe because there is no way to know
>> which register definitions were physical registers before RA
>> (e.g. to meet ABI or ISA constraints) and thus should not be
>> changed. I'd like to propose adding a bit to MachineOperand (by
>> overloading the meaning of the IsKill bit for defs, so no extra
>> storage would be required), that tracks whether a given register
>> definition was a virtual register before RA. I'll throw out
>> 'IsRenameable' for a potential name.
>> >
>> > Register definitions created with virtual registers would have
>> this bit set. This bit should be verifiable until after RA.
>> Register definitions created after RA (presumably with physical
>> registers) would not have this bit set. I believe the only
>> potential for this bit to be set incorrectly (and not be caught
>> be verification) would be if a post-RA pass was already renaming
>> a register definition from a previously virtual register to a
>> previously non-virtual register, which would arguably be a bug
>> already.
>> >
>> > We have encountered several potential uses for this bit. For
>> example, the MachineCopyPropagation changes I have been working
>> on to forward register COPYs would likely be greatly simplified
>> if this bit were available. Other passes, like
>> AArch64LoadStoreOptimizer, which run post-RA so as not to
>> overly-restrict the register allocator, could be made to catch
>> more cases if renaming of load instructions could be done safely.
>> >
>> > --
>> > Geoff Berry
>> > Employee of Qualcomm Datacenter Technologies, Inc.
>> > Qualcomm Datacenter Technologies, Inc. as an affiliate of
>> Qualcomm Technologies, Inc. Qualcomm Technologies, Inc. is a
>> member of the Code Aurora Forum, a Linux Foundation Collaborative
>> Project.
>>
>> _______________________________________________
>> LLVM Developers mailing list
>> llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>> <http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev>
>>
>>
>> _______________________________________________
>> LLVM Developers mailing list
>> llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
>
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
--
Hal Finkel
Lead, Compiler Technology and Programming Languages
Leadership Computing Facility
Argonne National Laboratory
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20171026/3d72f54e/attachment.html>
More information about the llvm-dev
mailing list