This is an archive of the discontinued LLVM Phabricator instance.

[CodeGen] Rename MachineInstr::isInvariantLoad to isDereferenceableInvariantLoad. NFC
ClosedPublic

Authored by jlebar on Aug 10 2016, 1:26 PM.

Details

Summary

I want to separate out the notions of invariance and dereferenceability
at the MI level, so that they correspond to the equivalent concepts at
the IR level. (Currently an MI load is MI-invariant iff it's
IR-invariant and IR-dereferenceable.)

First step is renaming this function.

Diff Detail

Repository
rL LLVM

Event Timeline

jlebar updated this revision to Diff 67592.Aug 10 2016, 1:26 PM
jlebar retitled this revision from to [CodeGen] Rename MachineInstr::isInvariantLoad to isDereferenceableInvariantLoad. NFC.
jlebar updated this object.
jlebar added a reviewer: chandlerc.
jlebar added a subscriber: llvm-commits.
chandlerc added inline comments.Aug 16 2016, 5:52 PM
llvm/include/llvm/CodeGen/MachineInstr.h
1131–1132 ↗(On Diff #67592)

typo: "return true of" -> "return true if"

llvm/lib/CodeGen/MachineInstr.cpp
1596 ↗(On Diff #67592)

No need to start with the function name.

Also, I'd format the comment to make it clear what the brief summary is while you're changing it.

jlebar updated this revision to Diff 68304.Aug 16 2016, 9:17 PM
jlebar marked an inline comment as done.

Address comment comments.

llvm/lib/CodeGen/MachineInstr.cpp
1596 ↗(On Diff #67592)

No need to start with the function name.

I don't like it either, but this is the prevailing style in the file, and the LLVM coding standards say (in bold) "If you are extending, enhancing, or bug fixing already implemented code, use the style that is already being used."?

Frankly if I were cleaning it up as a clean slate I'd delete the comment entirely, because it just repeats (verbatim) what's in the header.

Happy to do whatever you want here.

Also, I'd format the comment to make it clear what the brief summary is while you're changing it.

Done.

Friendly ping.

hfinkel added inline comments.
llvm/include/llvm/CodeGen/MachineInstr.h
1131 ↗(On Diff #68304)

The original text says, "invariant across the function", and it seems important that invariance here is restricted to during the execution of the current function body. Can/should you still capture this concept in the comment?

chandlerc accepted this revision.Aug 22 2016, 11:39 PM
chandlerc edited edge metadata.

FWIW, I agree with Hal. This patch LGTM with Hal's comment addressed.

This revision is now accepted and ready to land.Aug 22 2016, 11:39 PM

The original text says, "invariant across the function", and it seems important that invariance here is restricted to during the execution of the current function body.

If the comment is correct, I agree it's important to keep that part, but I'm not sure it is correct.

The function returns true if, for each load L done by the instruction,

  • L is MMO-invariant (meaning here that it is dereferenceable and has the !invariant.load IR annotation -- this patch comes before the one where we split out the notions of MMO-invariance and MMO-dereferenceability), or
  • L loads from a PseudoSourceValue that's constant, or
  • The address L is loading from points to constant memory.

I think this means that the load is invariant period, not invariant within the function?

jlebar updated this revision to Diff 69011.Aug 23 2016, 10:05 AM
jlebar edited edge metadata.

Reword comment.

Now that I'm looking at this again, I think we can improve the comment on this
function, but I still didn't change it back to saying that the load is
invariant across the function.

The original text says, "invariant across the function", and it seems important that invariance here is restricted to during the execution of the current function body.

If the comment is correct, I agree it's important to keep that part, but I'm not sure it is correct.

The function returns true if, for each load L done by the instruction,

  • L is MMO-invariant (meaning here that it is dereferenceable and has the !invariant.load IR annotation -- this patch comes before the one where we split out the notions of MMO-invariance and MMO-dereferenceability), or
  • L loads from a PseudoSourceValue that's constant, or

I think this is the point: These PseudoSourceValues can be things like addresses of things on the caller's stack (or on the stack in general) - they're not constant in some global sense, but they are constant during the execution of the current function. The stack itself is clearly not constant memory.

  • The address L is loading from points to constant memory.

I think this means that the load is invariant period, not invariant within the function?

reames added a subscriber: reames.Aug 23 2016, 12:20 PM
reames added inline comments.
llvm/include/llvm/CodeGen/MachineInstr.h
1127 ↗(On Diff #69011)

I think this comment is missing something major. In general, dereferenceability is a context-sensative property. In this query, the dereferenceable property is not context sensative and can only return true if the location is dereferenceable for any possible context. That should be clarified.

The "any possible context" bit is the issue Hal raises about function scope vs global scope. I believe we want function scope, but that implies we have to strip the relevant flag if we ever inline at the MI level. Do we actually do that?

jlebar updated this revision to Diff 69032.Aug 23 2016, 1:55 PM

Further update comments to clarify scope of invariance.

I think this is the point: These PseudoSourceValues can be things like addresses of things on the caller's stack

Ah, right, okay, thanks for clarifying that.

In general, dereferenceability is a context-sensative property. In this query, the dereferenceable property is not context sensative and can only return true if the location is dereferenceable for any possible context. That should be clarified.

I'm happy to clarify this, but I'm not sure how. The comment talks about a load instruction never trapping, so clearly we're talking about the memory location being dereferenceable within the context of the function?

Maybe it would be helpful if you could give a specific suggestion?

The "any possible context" bit is the issue Hal raises about function scope vs global scope. I believe we want function scope, but that implies we have to strip the relevant flag if we ever inline at the MI level. Do we actually do that?

AIUI (and I've been wrong now at least once, so take it fwiw) there's nothing to strip, because if we inline at the MI level and a load that once referenced constant memory no longer references constant memory, we'll notice that and the function will dtrt.

jlebar added a comment.Sep 6 2016, 5:13 PM

reames, Hal, friendly ping.

hfinkel accepted this revision.Sep 9 2016, 6:04 PM
hfinkel added a reviewer: hfinkel.
hfinkel added inline comments.
llvm/include/llvm/CodeGen/MachineInstr.h
1128 ↗(On Diff #69032)

"over the course of this function" sounds a bit too colloquial to me. Can we say, "during the execution of this function."?

Regardless, this LGTM too.

This revision was automatically updated to reflect the committed changes.
jlebar marked an inline comment as done.