Skip to content

Conversation

@katrinafyi
Copy link
Member

@katrinafyi katrinafyi commented Aug 25, 2025

there is a big problem here with the Top value. the new ValueAnalysis infrastructure expects a unique value top: Value but the top in TNum requires a bit width parameter. i've arbitrarily set the bv1 TNum.top(1) as "the" top value, and this causes the current test failures.

(also, the TNum lattice is actually not really valid because values with differing widths are incompatible - meet/join will fail when given different widths.)

maybe we need an abstraction of bit-width which would allow the use of width-dependent lattices and coerce to Top when widths differ.

@katrinafyi katrinafyi marked this pull request as draft August 25, 2025 05:34
i want to be able to pass a value of ValueLattice which defines only a
subset of the operations, to ensure that only width-independent
functions are called on the provided `top` value.

F-bound polymorphism makes it hideously hard to do this because any
provided value must conform to `T <: ValueLattice[T]`, effectively
forcing it to be a subtype of T (which is TNum here).

if we were to make this restricted ValueLattice a subtype of TNum, we
also have big problems. first, since TNum already defines all the
methods, we would need to override them with implementations that throw.
secondly, this overriding needs to happen in TNum and would need to be
repeated if we wanted to do the same for other instances of ValueLattice
in the future.

this is deeply unsatisfying. honestly, idk what to do. i think that the
"good" solution would be to make it all type-classes. then, we would be
able to split up the "static" ops (width independent) with the
non-static ops that need to be called on existing values.

it would be very good to avoid the dual-purpose of ValueLattice as both
a "dictionary of functions" and as a "lattice value". this is the root
of problems here. when we pass around an abitrary (non-sound) value to
access the directory of functions, we want to guarantee that the caller
does not access the lattice value methods, because it would be unsound
to do so.
also, seeing scalacheck failure which is concerning.
@katrinafyi
Copy link
Member Author

i've added a TypedLattice to abstract the bitwidth-dependence of the lattices

/**
* Derives a lattice for all [[ir.IRType]]s from the given type-specific [[TypedValueLattice]].
* This is done by wrapping the "inner" lattice into [[TypedLattice.Elem]]. New
* [[TypedLattice.Top]] and [[TypedLattice.Bot]] values are also introduced to act as
* universal (type-independent) top and bottom elements.
*
* If a type-specific operation is attempted on inner lattice values of incompatible type,
* the [[TypedValueLattice#handleConflictingTypes]] function is called.
*
* This [[TypedLattice]] class guarantees that the type-dependent methods of the inner
* [[TypedValueLattice]] are only called with values of compatible type. It also guarantees that
* the inner lattice's parameter-less [[ValueLattice#top]] and [[ValueLattice#bottom]]
* methods are _never_ called&mdash;instead, these are implemented by returning [[TypedLattice.Top]]
* and [[TypedLattice.Bot]], respectively.
*/
enum TypedLattice[T <: TypedValueLattice[T]](lattice: T) extends ValueLattice[TypedLattice[T]] {
case Bot(lattice: T) extends TypedLattice[T](lattice)
case Elem(inner: T) extends TypedLattice[T](inner)
case Top(lattice: T) extends TypedLattice[T](lattice)

however, there are still some problems:

  • it would be nice to allow the "inner" lattice operations to return the universal top/bot. however, this is kind of tricky because it would be mutually recursive or it would make it harder to define the cases which are width-specific or both.
  • F-bounded polymorphism is really annoying because it requires subtyping for customisation. however, subclassing the TypedLattice enum causes problems especially with the enum classes (which i believe wont pick up the subtyped parent class).

@katrinafyi katrinafyi marked this pull request as ready for review August 26, 2025 07:06
@katrinafyi
Copy link
Member Author

re being able to define both width-deoendent and -independent methods and being able to choose which to use, ig the thing can be the thingy blah blah method parameter dictionary of functions guh

@katrinafyi
Copy link
Member Author

related to #464

@github-actions
Copy link
Contributor

github-actions bot commented Sep 3, 2025

scalafmt check passed.

last updated at 8d66e17 (logs).

@katrinafyi katrinafyi force-pushed the valueanalysis-refactor-for-tnum branch from 0571287 to f400e11 Compare September 4, 2025 04:31
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants