Amara Emerson via llvm-dev
2021-Oct-05 23:24 UTC
[llvm-dev] Can DBG_VALUE instructions use undefined vregs?
That’s what we were doing in the legalizer, but calling eraseFromParentAndMarkDBGValuesForRemoval() is much more expensive than a plain eraseFromParent(), so the motivating change was to use a heuristic to avoid calling it when it was very likely that it wasn’t going to have a debug user. Whichever answer we get is fine, we can have a cleanup phase after legalization over all vregs in MachineRegisterInfo to mark ones without defs as undef, but I’d like to avoid doing that if we can so we don’t spend the extra compile time. Amara> On Oct 5, 2021, at 3:37 PM, Matthias Braun <matthiasb at fb.com> wrote: > > I can't really be speak about debug instructions in particular. For machine instructions in general you just mark the use operand with "undef" and you are good... > > - Matthias > >> On Oct 5, 2021, at 3:29 PM, Amara Emerson via llvm-dev <llvm-dev at lists.llvm.org> wrote: >> >> One GlobalISel compile time optimization patch (https://reviews.llvm.org/D109750) has generated some debate over whether it’s semantically allowed/not-an-error for a DBG_VALUE machine instruction to have a use of a vreg that doesn’t have a corresponding definition. >> >> We talked internally with Adrian and Vedant and didn’t come to a strong conclusion either way. Does anyone have thoughts here? >> >> Thanks, >> Amara >> _______________________________________________ >> LLVM Developers mailing list >> llvm-dev at lists.llvm.org >> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >
Matthias Braun via llvm-dev
2021-Oct-06 16:09 UTC
[llvm-dev] Can DBG_VALUE instructions use undefined vregs?
So you are asking about whether ... no definition of %X anywhere ... DBG_VALUE %x ; No undef flag here is fine. I think technically nothing will stop you. DBG_VALUE instructions are not real uses and ignored for anything semantically interesting like liveness etc. Thinking about it from this angle it wouldn't be that far fetched to just mark all DBG_VALUE operands as `undef`. On the other hand motivating this with `eraseFromParentAndMarkDBGValuesForRemoval` vs. `eraseFromParent` feels surprising... Somehow I would have assumed that once you finished all the work of creating a DBG_VALUE instruction and a register and multiple passes reading those instructions and operands, that one more iteration over the operands wouldn't really make a noticeable performance difference... - Matthias> On Oct 5, 2021, at 4:24 PM, Amara Emerson <amara at apple.com> wrote: > > That’s what we were doing in the legalizer, but calling eraseFromParentAndMarkDBGValuesForRemoval() is much more expensive than a plain eraseFromParent(), so the motivating change was to use a heuristic to avoid calling it when it was very likely that it wasn’t going to have a debug user. > > Whichever answer we get is fine, we can have a cleanup phase after legalization over all vregs in MachineRegisterInfo to mark ones without defs as undef, but I’d like to avoid doing that if we can so we don’t spend the extra compile time. > > Amara > >> On Oct 5, 2021, at 3:37 PM, Matthias Braun <matthiasb at fb.com> wrote: >> >> I can't really be speak about debug instructions in particular. For machine instructions in general you just mark the use operand with "undef" and you are good... >> >> - Matthias >> >>> On Oct 5, 2021, at 3:29 PM, Amara Emerson via llvm-dev <llvm-dev at lists.llvm.org> wrote: >>> >>> One GlobalISel compile time optimization patch (https://reviews.llvm.org/D109750 ) has generated some debate over whether it’s semantically allowed/not-an-error for a DBG_VALUE machine instruction to have a use of a vreg that doesn’t have a corresponding definition. >>> >>> We talked internally with Adrian and Vedant and didn’t come to a strong conclusion either way. Does anyone have thoughts here? >>> >>> Thanks, >>> Amara >>> _______________________________________________ >>> LLVM Developers mailing list >>> llvm-dev at lists.llvm.org >>> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >> >