llvm dev - Feb 2019 - Question about register allocation

Hi,
I'd like to understand how register allocation works in the case where an
instruction is folded into another one. Where in the code would be a good place
to start looking at?


After ISEL, one of the instructions has another instruction folded into it,
which looks like this

t1: i32,i1,i1,i1,i1 = ADDRR TargetFrameIndex:i32<0>, MOVRI:i32,i1,i1

But during the 'Assembly Printer' pass, when emitting the assembly for
ADDRR, the assertion at the beginning of getRegisterName() in
XXXGenAsmWriter.inc fails because RegNo is 0.
I'd like to know how that happened.

Thanks.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20190213/9beb0835/attachment.html>

On Tue, 12 Feb 2019 at 20:45, Josh Sharp via llvm-dev
<llvm-dev at lists.llvm.org> wrote:
> I'd like to understand how register allocation works in the case where
an instruction is folded into another one. Where in the code would be a good
place to start looking at?
I don't think you've got two instructions folded together. On the
output side that would just be a single instruction.
> After ISEL, one of the instructions has another instruction folded into it,
which looks like this
>
> t1: i32,i1,i1,i1,i1 = ADDRR TargetFrameIndex:i32<0>, MOVRI:i32,i1,i1
I've never seen anything displayed like that, and it worries me. I
thought only constants of some kind were inlined, which a MOVRI
instruction almost certainly doesn't qualify as.

 You'll want to look at how that's serialized after the DAG phase to
diagnose the issue. To the extent that it's meaningful, it ought to be
entirely equivalent to:

    %v0 = MOVRI [...]
    %t1 = ADDRR frameindex<0>, %v0, [...]

Generally, the "-print-after-all" option for llc is the quickest way
to access this kind of information. The first time the ADDRR
instruction occurs is just after an opaque "DAG ISel" phase that
you've been introspecting.
> But during the 'Assembly Printer' pass, when emitting the assembly
for ADDRR, the assertion at the beginning of getRegisterName() in
XXXGenAsmWriter.inc fails because RegNo is 0. I'd like to know how that
happened.
Assembly printer is very late. In fact it's the very last pass LLVM
runs. Generally any assertion failure there can be traced to bad input
(unless you're literally implementing the AsmPrinter at the time),
which again points to "-print-after-all" as a diagnostic tool.

There's usually something obviously wrong with the final instructions,
which can be traced back to something less-obviously-but-still wrong
before register allocation (often mismatched register classes). The
trick is establishing the first phase were things are incorrect and
working out why.
>From what you've said I'd bet on ISel unfortunately (it's a big
phase).
Cheers.

Tim.

Thanks Tim,

The -print-after-all option did help. The problem happens after
Prologue/epilogue insertion

# *** IR Dump After Fast Register Allocator ***:
# Machine code for function _Z16test_rotate_leftv: NoPHIs, TracksLiveness,
NoVRegs
Frame Objects:
  fi#0: size=4, align=4, at location [SP]

  $r0 = ADDR %stack.0.a, $r0(tied-def 0), implicit-def dead $cf, implicit-def
dead $nf, implicit-def dead $zf, implicit-def dead $of

# End machine code for function _Z16test_rotate_leftv.

# *** IR Dump After Prologue/Epilogue Insertion & Frame Finalization ***:
# Machine code for function _Z16test_rotate_leftv: NoPHIs, TracksLiveness,
NoVRegs
Frame Objects:
  fi#0: size=4, align=4, at location [SP-4]

  $r0 = ADDR $noreg, $r0(tied-def 0), implicit-def dead $cf, implicit-def dead
$nf, implicit-def dead $zf, implicit-def dead $of


Somehow '%stack.0.a' became '$noreg'

Other than XXXSEFrameLowering::emitPrologue(), what other function is called
when entering a function?

Thanks.

________________________________
From: Tim Northover <t.p.northover at gmail.com>
Sent: Tuesday, February 12, 2019 9:07 PM
To: Josh Sharp
Cc: via llvm-dev
Subject: Re: [llvm-dev] Question about register allocation

On Tue, 12 Feb 2019 at 20:45, Josh Sharp via llvm-dev
<llvm-dev at lists.llvm.org> wrote:
> I'd like to understand how register allocation works in the case where
an instruction is folded into another one. Where in the code would be a good
place to start looking at?
I don't think you've got two instructions folded together. On the
output side that would just be a single instruction.
> After ISEL, one of the instructions has another instruction folded into it,
which looks like this
>
> t1: i32,i1,i1,i1,i1 = ADDRR TargetFrameIndex:i32<0>, MOVRI:i32,i1,i1
I've never seen anything displayed like that, and it worries me. I
thought only constants of some kind were inlined, which a MOVRI
instruction almost certainly doesn't qualify as.

 You'll want to look at how that's serialized after the DAG phase to
diagnose the issue. To the extent that it's meaningful, it ought to be
entirely equivalent to:

    %v0 = MOVRI [...]
    %t1 = ADDRR frameindex<0>, %v0, [...]

Generally, the "-print-after-all" option for llc is the quickest way
to access this kind of information. The first time the ADDRR
instruction occurs is just after an opaque "DAG ISel" phase that
you've been introspecting.
> But during the 'Assembly Printer' pass, when emitting the assembly
for ADDRR, the assertion at the beginning of getRegisterName() in
XXXGenAsmWriter.inc fails because RegNo is 0. I'd like to know how that
happened.
Assembly printer is very late. In fact it's the very last pass LLVM
runs. Generally any assertion failure there can be traced to bad input
(unless you're literally implementing the AsmPrinter at the time),
which again points to "-print-after-all" as a diagnostic tool.

There's usually something obviously wrong with the final instructions,
which can be traced back to something less-obviously-but-still wrong
before register allocation (often mismatched register classes). The
trick is establishing the first phase were things are incorrect and
working out why.
>From what you've said I'd bet on ISel unfortunately (it's a big
phase).
Cheers.

Tim.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20190215/97c449dd/attachment.html>