This is an archive of the discontinued LLVM Phabricator instance.

[TargetRegisterInfo, AArch64] Add target hook for isConstantPhysReg().
ClosedPublic

Authored by gberry on Sep 14 2016, 9:19 AM.

Details

Summary

The current implementation of isConstantPhysReg() checks for defs of
physical registers to determine if they are constant. Some
architectures (e.g. AArch64 XZR/WZR) have registers that are constant
and may be used as destinations to indicate the generated value is
discarded, preventing isConstantPhysReg() from returning true. This
change adds a TargetRegisterInfo hook that overrides the no defs check
for cases such as this.

Diff Detail

Event Timeline

gberry updated this revision to Diff 71373.Sep 14 2016, 9:19 AM
gberry retitled this revision from to [TargetRegisterInfo, AArch64] Add target hook for isConstantPhysReg()..
gberry updated this object.
gberry added subscribers: mcrosier, junbuml.
MatzeB added inline comments.Sep 14 2016, 9:55 AM
include/llvm/Target/TargetRegisterInfo.h
498–499

This needs a comment (even if it just refers to MachineRegisterInfo::isConstantPhysReg())!
You may want to use MCPhysReg instead of unsigned to indicate it is only valid for physregs.

Testcase?

I'm looking into that now.

I meant to add this before: I'm interested to hear opinions on whether adding a virtual function call for this is okay, or if this bit should instead say be cached in TargetRegisterInfoDesc like inAllocatableClass is.

Also, this change potentially fixes https://llvm.org/bugs/show_bug.cgi?id=25457

MatzeB edited edge metadata.Sep 14 2016, 11:03 AM

I meant to add this before: I'm interested to hear opinions on whether adding a virtual function call for this is okay, or if this bit should instead say be cached in TargetRegisterInfoDesc like inAllocatableClass is.

Hard to say in general. Depends on how it is called, whether most implementations are just a few equality comparisons, ...

It looks good enough for todays uses. You could do some measurements though I wouldn't expect any compiletime differences. We can always add more caching later when necessary.

I meant to add this before: I'm interested to hear opinions on whether adding a virtual function call for this is okay, or if this bit should instead say be cached in TargetRegisterInfoDesc like inAllocatableClass is.

Hard to say in general. Depends on how it is called, whether most implementations are just a few equality comparisons, ...

It looks good enough for todays uses. You could do some measurements though I wouldn't expect any compiletime differences. We can always add more caching later when necessary.

That was pretty much my thinking as well.

gberry updated this revision to Diff 71533.Sep 15 2016, 12:02 PM
gberry edited edge metadata.

Added comment and test case

MatzeB accepted this revision.Sep 27 2016, 1:00 PM
MatzeB edited edge metadata.

LGTM, but please simplify the test as much as possible before committing:

test/CodeGen/MIR/AArch64/machine-sink-zr.mir
4–20 ↗(On Diff #71533)

I believe there is no need for any backreference here and you can simplify this to define void @sinkwzr() { ret void } (see below for how to block names).

24–29 ↗(On Diff #71533)

I would expect that the default values are fine for those options so you don't need to specify them here.

40 ↗(On Diff #71533)

I would add a CHECK-LABEL: name: sinkwzr to get the checker on the right function (in case people add more functions to this test in the future).

42 ↗(On Diff #71533)

You can simply use bb.0: here to avoid the backreference to the IR code (similar with all other basic block names).

This revision is now accepted and ready to land.Sep 27 2016, 1:00 PM
This revision was automatically updated to reflect the committed changes.