implicit CC register Defs cause "physreg was not killed in defining block!" assert

Project Infrastructure LLVM Dev List Archives
#1

Hello,

For my backend, I define and use a CC register similiarly to the EFLAGS register in X86 (I call it CCFLAGS).
But if I make all arithmetic/logic instructions affect it ('let Defs = [CCFLAGS] in...' in InstrInfo.td) I run into

  // The only case we should have a dead physreg here without a killing or
  // instruction where we know it's dead is if it is live-in to the function
  // and never used.
  assert(!CopyMI && "physreg was not killed in defining block!");

in LiveIntervals::handlePhysicalRegisterDef().

The dump() of the MBB from the debugger looks like the following:

entry.ifcont267_crit_edge: 0x12bc368, LLVM BB @0x12bb900, ID#2:
    Predecessors according to CFG: 0x12bc290 (#0) 0x12bca70 (#1)
        %reg1033<def> = addC %reg1025<kill>, 0, %CCFLAGS<imp-def,dead>
        %reg1032<def> = addC %reg1024<kill>, 0, %CCFLAGS<imp-def,dead>
        %reg1095<def> = addC %reg1028, 0, %CCFLAGS<imp-def>
        %reg1096<def> = addC %reg1029<kill>, 0, %CCFLAGS<imp-def>
        %reg1097<def> = addC %reg1033<kill>, 0, %CCFLAGS<imp-def>
        %reg1098<def> = addC %reg1028<kill>, 0, %CCFLAGS<imp-def>
        %reg1099<def> = addC %reg1031<kill>, 0, %CCFLAGS<imp-def>
        %reg1100<def> = addC %reg1030, 0, %CCFLAGS<imp-def>
        %reg1101<def> = addC %reg1032<kill>, 0, %CCFLAGS<imp-def>
        %reg1102<def> = addC %reg1030<kill>, 0, %CCFLAGS<imp-def>
        br mbb<ifcont267,0x12bc518>
    Successors according to CFG: 0x12bc518 (#4)

Do you have any idea what could be wrong, or how to further debug the problem?

Thanks a lot,
Christian

#2

A physical register cannot be live across the block. So it must have a use in the block or it must be marked dead. From your dump, it looks like the CCFLAGS defs are not being marked dead. It's unclear where things went wrong, but you can step through LiveVariables to debug this.

Evan

#3

Evan,

A physical register cannot be live across the block. So it
must have a use in the block or it must be marked dead. From
your dump, it looks like the CCFLAGS defs are not being marked
dead. It's unclear where things went wrong, but you can step
through LiveVariables to debug this.

Thanks for your response. I did quite some stepping through the llc
passes, and it turned out what now looks fairly obvious:
The instructions containing the CCFLAGS which are not marked dead
in the dump below (line 3+) are reg-to-reg copies inserted by the PHI elimination.
In my backend, a mov instruction is currently implemented as an add with
constant 0 (affecting condition codes).
Now LiveVariables gets executed before PHI elimination, so I am trying
to figure out if there is code in PNE which is supposed to update the
defs. Otherwise I might try to re-run LiveVariables after PNE, or
some similiar approach combining these two passes - unless you tell
me they don't get marked dead because of an implementation flaw in my
backend (or something completely else : )

Thanks again,
Christian

#4

Hi,

I was a little confused by all the passes I went through last time.
LiveVariables *is* actually being run before and after PNE (of course,
because it crashed in the second run...)

The problem was that the CCFLAGS register was not marked
non-allocatable. AFAICS this is also the case in the X86 backend, which
I took as model, although it does not make problems there - but maybe
it should not be anyway?

The instructions containing the CCFLAGS which are not marked dead
in the dump below (line 3+) are reg-to-reg copies inserted by
the PHI elimination.
In my backend, a mov instruction is currently implemented as
an add with
constant 0 (affecting condition codes).
Now LiveVariables gets executed before PHI elimination, so I am trying
to figure out if there is code in PNE which is supposed to update the
defs. Otherwise I might try to re-run LiveVariables after PNE, or
some similiar approach combining these two passes - unless you tell
me they don't get marked dead because of an implementation flaw in my
backend

...which turned out to be the correct assumption ; )

Regards,
Christian