This is an archive of the discontinued LLVM Phabricator instance.

[CostModel] Model all `extractvalue`s as free.
ClosedPublic

Authored by lebedev.ri on Aug 12 2019, 11:04 AM.

Diff Detail

Repository
rL LLVM

Event Timeline

lebedev.ri created this revision.Aug 12 2019, 11:04 AM

LGTM, though are we sure this is true for all targets? The comments in the referenced patch only consider X86. I'm pretty sure it is true for common architectures like AArch64 but I'm not as sure for more exotic things.

LGTM, though are we sure this is true for all targets? The comments in the referenced patch only consider X86. I'm pretty sure it is true for common architectures like AArch64 but I'm not as sure for more exotic things.

I have asked the exact same question before:

Did anything happen with the extractvalue cost suggestion?

I was planning to look into that, and i just did. Some observations:

  1. I'm not sure we can literally treat any extractvalue as free, it clearly isn't: https://godbolt.org/z/6wIxAa

For the short cases, the mov belongs to the return not the extractvalue. For the large cases all of that code is the result of passing an array by value.

So it seems to be the right thing to do..

LGTM, though are we sure this is true for all targets? The comments in the referenced patch only consider X86. I'm pretty sure it is true for common architectures like AArch64 but I'm not as sure for more exotic things.

I have asked the exact same question before:

Did anything happen with the extractvalue cost suggestion?

I was planning to look into that, and i just did. Some observations:

  1. I'm not sure we can literally treat any extractvalue as free, it clearly isn't: https://godbolt.org/z/6wIxAa

For the short cases, the mov belongs to the return not the extractvalue. For the large cases all of that code is the result of passing an array by value.

So it seems to be the right thing to do..

Well, my point is that thread only considers X86. Are we sure this is true for all targets?

Can anyone from non-X86 comment if this assumption still holds for those arches?
I suspect it does, but would be good to confirm.

I can't think of a counterexample for the other architectures I know about.

I can't think of a counterexample for the other architectures I know about.

That is reassuring, and in-line with other comments.
Does anyone feel confident-enough about it to review/stamp?

jmolloy accepted this revision.Aug 29 2019, 3:52 AM

I think I'm happy to stamp. I can't think of why this patch might be wrong, and it's easy to back out if someone finds a counterexample. LGTM.

This revision is now accepted and ready to land.Aug 29 2019, 3:52 AM

I ran some ARM and AArch64 tests, which agreed that this is OK for those architectures (although they are probably already covered by what James said above).

I think I'm happy to stamp. I can't think of why this patch might be wrong, and it's easy to back out if someone finds a counterexample. LGTM.

I ran some ARM and AArch64 tests, which agreed that this is OK for those architectures (although they are probably already covered by what James said above).

Thank you for the review!

This revision was automatically updated to reflect the committed changes.