This is an archive of the discontinued LLVM Phabricator instance.

[SystemZ::TTI] i8/i16 operands extension cost revisited
ClosedPublic

Authored by jonpa on Nov 29 2018, 6:07 AM.

Details

Reviewers
uweigand
Summary

I have in this patch looked at the extra costs added for i8/16 instructions that requires the operands to be sign/zero extended.

Three minor changes:

  • The operands extension cost for divides could be removed with NFC on spec. This should be because we now have such a high cost already for the divide (20).
  • I started looking at the costs for lhsr/ashr and added a check if the shifted value is a load, in which case it should not be needed. This seemed like an improvement... However, since nearly all the cases here were loads, I tried removing this entirely, so that all lhsr/ashr instructions get a cost of 1 no matter the bitwidth. This was nearly the same result - just one file changed by SLP and probably for the better. So it seemed this could be removed, which I did.
  • For ICmp instructions, instead of adding 2 all the time for extending each operand, this is only done if that operand is neither a load or an immediate. Again, this seemed like an improvement, but I also tried removing the extra cost entirely. There were a few more changes there on benchmark, so I ended up not removing it.

I am however not sure this extra function is really motivated and could perhaps look in more detail what happens if I remove it. It seemed at least in the one case I looked at where things changed (after removing all extra costs) that there actually was not any extra extension of the operand, so it seems again that this does not happen all the time.

I could remove the check for a comparison of memory with a small immediate, since those cases have a 0 operands extension cost, which is equivalent to checking the operands per this patch.

I am not really sure anymore about considering these instructions to require extensions of the operands. It's hard to tell when this is really needed or not. This patch adds the awareness of cases when this should not be needed, for instance in the case of a load, so in that sense it's an improvement at least.

Diff Detail

Event Timeline

jonpa created this revision.Nov 29 2018, 6:07 AM
uweigand accepted this revision.Nov 29 2018, 12:11 PM

LGTM, thanks!

This revision is now accepted and ready to land.Nov 29 2018, 12:11 PM
jonpa closed this revision.Nov 29 2018, 11:13 PM

r347961