This is an archive of the discontinued LLVM Phabricator instance.

[CodeGen] Refactor MachineMemOperand's Flags enum.
ClosedPublic

Authored by jlebar on Jul 12 2016, 3:03 PM.

Details

Summary
  • Give it a shorter name (because we're going to refer to it often from SelectionDAG and friends).
  • Specialize FlagsEnumTraits for it, so we can do bitwise ops on it without losing type information.
  • Make some enum values constants in MachineMemOperand instead. MOMaxBits should not be a valid Flag.
  • Simplify some of the bitwise ops for dealing with Flags.

Diff Detail

Repository
rL LLVM

Event Timeline

jlebar updated this revision to Diff 63733.Jul 12 2016, 3:03 PM
jlebar retitled this revision from to [CodeGen] Refactor MachineMemOperand's Flags enum..
jlebar updated this object.
jlebar added a reviewer: chandlerc.
jlebar added a subscriber: llvm-commits.
jlebar updated this revision to Diff 63748.Jul 12 2016, 4:27 PM

Fix typo.

MatzeB added a subscriber: MatzeB.Jul 12 2016, 5:28 PM

How about something like:

uint16_t Flags : 8;
uint16_t Align : 8;

so we can leave the bit fiddeling to the compiler?

How about something like:

uint16_t Flags : 8;
uint16_t Align : 8;

so we can leave the bit fiddeling to the compiler?

Typo, I meant

uint16_t Flags;
uint16_t Align;
```.
jlebar updated this revision to Diff 63769.Jul 12 2016, 7:14 PM

Split flags and alignment into separate variables.

so we can leave the bit fiddeling to the compiler?

Well that's a crazy idea. Done, thank you.

MatzeB added inline comments.Jul 12 2016, 8:15 PM
include/llvm/CodeGen/MachineMemOperand.h
102 ↗(On Diff #63769)

You could change this to enum Flags : uint16_t {...} so that spltting the alignment won't make the MemOperands larger than before.
I assume the MOMaxFlag can is unnecessary as well now?

chandlerc added inline comments.Jul 12 2016, 8:22 PM
include/llvm/CodeGen/MachineMemOperand.h
102 ↗(On Diff #63769)

a fixed underlying type can't *shrink* an enum... if it only requires <= 16 bits to represent the largest enumerator, that's how many bits you'll get?

MatzeB added inline comments.Jul 12 2016, 8:31 PM
include/llvm/CodeGen/MachineMemOperand.h
102 ↗(On Diff #63769)

Unfortunately all popular compilers out there choose unsigned/int even for smaller enums, so explicitely shrinking it is important!

jlebar updated this revision to Diff 63810.Jul 13 2016, 9:01 AM
jlebar marked 3 inline comments as done.

Give the Flags enum an explicit storage type.

include/llvm/CodeGen/MachineMemOperand.h
102 ↗(On Diff #63769)

Yes, of course -- this got lost while I was bisecting a bug in my changes. Sorry about that.

jlebar marked an inline comment as done.Jul 13 2016, 9:02 AM
jlebar updated this revision to Diff 63822.Jul 13 2016, 10:37 AM

Update to latest version of bitmask enum patch.

chandlerc edited edge metadata.Jul 14 2016, 1:57 AM

FYI, this LGTM. Good to get Matthias's Ok before you land it though as this is a more involved change.

MatzeB accepted this revision.Jul 14 2016, 9:23 AM
MatzeB added a reviewer: MatzeB.

Looks good to me.

Possible style suggestions below, they are personal style, I won't mind if you decide against changing it:

include/llvm/CodeGen/MachineMemOperand.h
92–97 ↗(On Diff #63822)

Outside of the enum I find it more dangerous that those are forgotten when someone updates the enum.

I also wanted to point out that we can solve target flags in a slightly more elegant way. Though we should change one thing at a time and better leave this bit for another day/patch:

enum Flags { ...
  MOInvariant = 16,
  MOFirstTargetFlag = 32,
  ...

in target code:

enum TargetFlags { ...
  MOTargetFlag1 = MOFirstTargetFlag << 0,
  MOTargetFlag2 = MOFirstTargetFlag << 1,
  MOTargetFlag3 = MOFirstTargetFlag << 2,
  ...
};
100 ↗(On Diff #63822)

MOMaxBits == 8 so this can be uint8_t I presume.

102–110 ↗(On Diff #63822)

Another bit possibly for another day/another patch. I prefer this style:

MONone = 0,
MOLoad = 1u << 0,
MOStore = 1u << 1,
MOVolatile = 1u << 2,
MONonTemporal = 1u << 3,
MOInvariant = 1u << 4,
//...
This revision is now accepted and ready to land.Jul 14 2016, 9:23 AM

Thank you for the review, Matthias and Chandler.

include/llvm/CodeGen/MachineMemOperand.h
92–97 ↗(On Diff #63822)

While I agree with your point about the increased likelihood that these constants will fall out of sync if they're outside the enum, I nonetheless think it's right for them to be there, because otherwise you could do

Flags f = MOInvariant | MOTargetStartBit;

which is a (logical) type error.

Your idea about naming explicit target flags in the enum is interesting. I'm afraid it may be obfuscating, but maybe you can do

constexpr Flags MOMyNamedTargetFlag = Flags::MOTargetFlag2;

I guess that's better than

constexpr Flags MOMyNamedTargetFlag = Flags::MOFirstTargetFlag << 1;

although the target flags are used so infrequently that it doesn't bother me too much. There are much bigger fish to fry here. :)

100 ↗(On Diff #63822)

I think I'd rather keep it as a uint16 -- we have the space in the structure, and I would rather make someone think twice before using that space for something other than flags. (Also the reason I'm doing all this refactoring is I want to add another bit here. :)

This revision was automatically updated to reflect the committed changes.

Possible style suggestions below, they are personal style, I won't mind if you decide against changing it:

You were right, sending a patch with all these changes. Better than forgetting to define the static const members in the cpp file...