You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We can safely transform an ASSIGNED var into a LOCAL iff the following condition holds for all API blocks
in an NMODL mechanism:var written before it's read. If var is never read, we can remove it alltogether.
The only wrinkle are if-then-else statements, but these are fine with a bit of care.
For that consider both arms (if present!) individually and merge their reads and
writes:
if 'written-before-read' is true for both branches, then it's true overall
if 'written-before-read' is true for one branch, dismiss and proceed
if it's false for one branch, it's false overall
if var is written in one branch, dismiss this fact
if var is written in both branches, propagate that fact.
but there it's questionable (without a cost model depending on the backend CPU/SIMD/GPU) whether it's
an optimisation anyhow. These could be recovered by ordering the blocks (and their possible interleavings,
potentially) by the order prescribed by fvm_lowered_cell::integrate, but I consider this quite brittle.
The text was updated successfully, but these errors were encountered:
This also requires at least a primitive cost model as things that are expensive to compute and never change are worth writing to memory. That also might depend on CPU ./. GPU.
We can safely transform an ASSIGNED
var
into a LOCAL iff the following condition holds for all API blocksin an NMODL mechanism:
var
written before it's read. Ifvar
is never read, we can remove it alltogether.The only wrinkle are if-then-else statements, but these are fine with a bit of care.
For that consider both arms (if present!) individually and merge their reads and
writes:
We miss some cases
but there it's questionable (without a cost model depending on the backend CPU/SIMD/GPU) whether it's
an optimisation anyhow. These could be recovered by ordering the blocks (and their possible interleavings,
potentially) by the order prescribed by
fvm_lowered_cell::integrate
, but I consider this quite brittle.The text was updated successfully, but these errors were encountered: