Are enum members literals or constants in an IR?

Question

While implementing enums in Tyr, I just realized that enum constants are the only form of literal-like entity that is not represented like a literal in the intermediate representation.

The enum concept is pretty much that of C++. I doubt that it really matters for the question. The question is, are there any benefits from having enum members as literals in the IR?

My current approach is essentially treating them like global constants that are somewhat equal to the literal values they correspond to. There are some places in the compiler with special rules projecting the enum types away.

At the moment, I'd expect that the answer doesn't even depend on the representation of the enum concept or if instances are flat values or String literals or arbitrary Objects.

EDIT: The question is if a literal type distinct from the literal type of the enum's base type should be introduced. In contrast to projecting the instances to the base type which wasn't the intention, but is apparently a sane interpretation of the original question.

EDIT2: The IR is used to build libraries that can be linked, compiled against and executed like JAR files in Java. The question is if a dedicated EnumLiteral expression subclass akin to an IntLiteral has any obvious advantage or disadvantage over a combination of StaticUse Expression with an EnumInstance Declaration target. Both options would bear an access path to the enum type and the underlying IntLiteral.

Answer 1

If your enum members are backed by simple immutable integers or strings, and are used as simple names in lieu of these simple integers/strings, they can be represented as simple literals or constants anywhere, even in IR.

But if these enums defines a closed set of possible values or exhaustiveness checking, they are very distinct of simple literals, and should be represented differently:

enum mixed {
  zero,
  one,
  two
}

type T {
  with mixed.zero
  with mixed.one
  with mixed.two

  test "use" {
   
    val c = one + two   // compiler accepts or fails?

    switch c {
      if zero true
      if one true
      if two true
      else false        // compiler complains can never happen?
    }
  }
}

On an IR very close to code generation, after all type checking is already done, is possible to replace enums members by their direct literal values, as in this level these substitutions do not generate invalid effects.

At a very low level, code folding and constant propagation don't care if an immutable value is a member of an enum, a class constant, or a source code literal.