[BitmaskEnum] Add support for shift operators. (#118007)

For enums that describe a bitmask where successive bits within that mask
describe some enum value (as described in the same enum), it is use

[BitmaskEnum] Add support for shift operators. (#118007)

For enums that describe a bitmask where successive bits within that mask
describe some enum value (as described in the same enum), it is useful
to support operator<< and operator>> as well.

For example:
```
enum class E : unsigned {
// 2 bits per option
OptionA = 0,
OptionB = 1,
OptionC = 2,
OptionD = 3,
OptionMask = 3,

// Given 3 values in the bitmask X, Y and Z, each is 2 bits in size
// and represents a choice of OptionA..OptionD.
ShiftX = 0,
ShiftY = 2,
ShiftZ = 4,
};

// The mask can be encoded with:
E mask;
mask |= getOptionFor(X) << E::ShiftX;
mask |= getOptionFor(Y) << E::ShiftY;
mask |= getOptionFor(Z) << E::ShiftZ;

// And to extract a value:
E OptionForX = (mask >> E::ShiftX) & E::OptionMask;
E OptionForY = (mask >> E::ShiftY) & E::OptionMask;
E OptionForZ = (mask >> E::ShiftZ) & E::OptionMask;
```

show more ...

[NFC] Make FPClassTest a bitmask enumeration

This is recommit of 2e416cdd52, fixed to be accepatble by GCC.
The original commit message is below.

With this change bitwise operations are allowed for

[NFC] Make FPClassTest a bitmask enumeration

This is recommit of 2e416cdd52, fixed to be accepatble by GCC.
The original commit message is below.

With this change bitwise operations are allowed for FPClassTest
enumeration, it must simplify using this type. Also some functions
changed to get argument of type FPClassTest instead of unsigned.

Differential Revision: https://reviews.llvm.org/D144241

show more ...

[ADT] Alternative way to declare enum type as bitmask

If an enumeration represents a set of bit flags, using the macro
LLVM_MARK_AS_BITMASK_ENUM can make operations with such enumeration more
conven

[ADT] Alternative way to declare enum type as bitmask

If an enumeration represents a set of bit flags, using the macro
LLVM_MARK_AS_BITMASK_ENUM can make operations with such enumeration more
convenient. It however brings problems if the enumeration is non-scoped.
As the macro adds an item LLVM_BITMASK_LARGEST_ENUMERATOR to the
enumeration type, only one such type may be declared as bitmask. This
problem could be solved by convertion of the enumeration to scoped, but
it requires static_casts in new places and the convenience can be
eliminated.

This change introduces a new macro LLVM_DECLARE_ENUM_AS_BITMASK, which
allows non-invasive convertion of an enumeration into bitmask. It
provides specialization to trait classes, which previously were built
based on presence of LLVM_BITMASK_LARGEST_ENUMERATOR in the enumeration.
The macro must be specified in global or llvm namespace because the
trait classes are declared in llvm namespace.

Differential Revision: https://reviews.llvm.org/D144202

show more ...

[ADT] Make BitmaskEnum operations constant expressions

This avoids runtime initialization (a global constructor) whenever they appear
in the initializer.

The patch just adds the constexpr keyword t

[ADT] Make BitmaskEnum operations constant expressions

This avoids runtime initialization (a global constructor) whenever they appear
in the initializer.

The patch just adds the constexpr keyword to a couple of functions.

Differential Revision: https://reviews.llvm.org/D121281

show more ...

Update the file headers across all of the LLVM projects in the monorepo
to reflect the new license.

We understand that people may be surprised that we're moving the header
entirely to discuss the ne

Update the file headers across all of the LLVM projects in the monorepo
to reflect the new license.

We understand that people may be surprised that we're moving the header
entirely to discuss the new license. We checked this carefully with the
Foundation's lawyer and we believe this is the correct approach.

Essentially, all code in the project is now made available by the LLVM
project under our new license, so you will see that the license headers
include that license only. Some of our contributors have contributed
code under our old license, and accordingly, we have retained a copy of
our old license notice in the top-level files in each project and
repository.

llvm-svn: 351636

show more ...

[ADT] Add LLVM_MARK_AS_BITMASK_ENUM, used to enable bitwise operations on enums without static_cast.

Summary: Normally when you do a bitwise operation on an enum value, you
get back an instance of t

[ADT] Add LLVM_MARK_AS_BITMASK_ENUM, used to enable bitwise operations on enums without static_cast.

Summary: Normally when you do a bitwise operation on an enum value, you
get back an instance of the underlying type (e.g. int). But using this
macro, bitwise ops on your enum will return you back instances of the
enum. This is particularly useful for enums which represent a
combination of flags.

Suppose you have a function which takes an int and a set of flags. One
way to do this would be to take two numeric params:

enum SomeFlags { F1 = 1, F2 = 2, F3 = 4, ... };
void Fn(int Num, int Flags);

void foo() {
Fn(42, F2 | F3);
}

But now if you get the order of arguments wrong, you won't get an error.

You might try to fix this by changing the signature of Fn so it accepts
a SomeFlags arg:

enum SomeFlags { F1 = 1, F2 = 2, F3 = 4, ... };
void Fn(int Num, SomeFlags Flags);

void foo() {
Fn(42, static_cast<SomeFlags>(F2 | F3));
}

But now we need a static cast after doing "F2 | F3" because the result
of that computation is the enum's underlying type.

This patch adds a mechanism which gives us the safety of the second
approach with the brevity of the first.

enum SomeFlags {
F1 = 1, F2 = 2, F3 = 4, ..., F_MAX = 128,
LLVM_MARK_AS_BITMASK_ENUM(F_MAX)
};

void Fn(int Num, SomeFlags Flags);

void foo() {
Fn(42, F2 | F3); // No static_cast.
}

The LLVM_MARK_AS_BITMASK_ENUM macro enables overloads for bitwise
operators on SomeFlags. Critically, these operators return the enum
type, not its underlying type, so you don't need any static_casts.

An advantage of this solution over the previously-proposed BitMask class
[0, 1] is that we don't need any wrapper classes -- we can operate
directly on the enum itself.

The approach here is somewhat similar to OpenOffice's typed_flags_set
[2]. But we skirt the need for a wrapper class (and a good deal of
complexity) by judicious use of enable_if. We SFINAE on the presence of
a particular enumerator (added by the LLVM_MARK_AS_BITMASK_ENUM macro)
instead of using a traits class so that it's impossible to use the enum
before the overloads are present. The solution here also seamlessly
works across multiple namespaces.

[0] http://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20150622/283369.html
[1] http://lists.llvm.org/pipermail/llvm-commits/attachments/20150623/073434b6/attachment.obj
[2] https://cgit.freedesktop.org/libreoffice/core/tree/include/o3tl/typed_flags_set.hxx

Reviewers: chandlerc, rsmith

Subscribers: llvm-commits

Differential Revision: http://reviews.llvm.org/D22279

llvm-svn: 275292

show more ...