Nicholas Curtis <nicholas.curtis(a)uconn.edu> writes:
> I don't understand the leaf domain / domain ordering affects code
> generation ¯\_(ツ)_/¯
>
> For example, in running the following code:
>
> https://gist.github.com/arghdos/f8b4e7a700776c6f7f2c22e7087b9dd3
>
> generates the error:
>
> loopy.diagnostic.LoopyError: sanity check failed--implemented and desired
> domain for instruction 'insn_2' do not match
>
> implemented: [end, start] -> { [k, l, j, i] : 0 <= k <= 999 and 0 <= l <=
> 99 and start <= j < end and start <= i < end }
>
> desired:[end, start] -> { [k, l, j, i] : 0 <= k <= 999 and 0 <= l <= 99 and
> start <= j < end }
>
> sample point in desired but not implemented: start=1, end=2, i=0, k=0, j=1,
> l=0
> gist of constraints in implemented but not desired: [end, start] -> { [k,
> l, j, i] : start <= i < end }
>
>
> (see the gist for formatting)
>
> However, if I change the order of the domains in the gist such that it goes
> (i, j, k, l)---again, see the gist---the code generates correctly.
>
> Is this a function of my not understanding how the domain / leaf structure
> works? Or have I found a bug?
Both. :) Your code is ill-formed, and it should have complained much
sooner/better. The latter is fixed here:
https://gitlab.tiker.net/inducer/loopy/merge_requests/115
It now says:
loopy.diagnostic.CannotBranchDomainTree: iname set 'l, i, j, k' requires branch in domain tree (when adding 'j')
The former here:
https://gist.github.com/inducer/cc4e3e30f3d4c7a3f33c35246ff00cab#file-gistf…
You can (sort of) see the domain forest when you print the kernel:
{ [k] : 0 <= k <= 4 }
{ [l] : 0 <= l <= 2 }
[end, start] -> { [i] : start <= i < end }
[end, start] -> { [j] : start <= j < end }
The i and j domains are "children" of the l domain.
The idea is that domains form a forest (a collection of trees), and a
"sub-forest" is extracted that covers all the inames for each
instruction. Each individual sub-tree is then checked for branching,
which is ill-formed. It is declared ill-formed because intersecting, in
your case, the l, i, and j domains could result in restrictions from the
i domain affecting the j domain by way of how i affects l--which would
be counterintuitive to say the least.) I've also added this to the docs.
HTH,
Andreas

I don't understand the leaf domain / domain ordering affects code
generation ¯\_(ツ)_/¯
For example, in running the following code:
https://gist.github.com/arghdos/f8b4e7a700776c6f7f2c22e7087b9dd3
generates the error:
loopy.diagnostic.LoopyError: sanity check failed--implemented and desired
domain for instruction 'insn_2' do not match
implemented: [end, start] -> { [k, l, j, i] : 0 <= k <= 999 and 0 <= l <=
99 and start <= j < end and start <= i < end }
desired:[end, start] -> { [k, l, j, i] : 0 <= k <= 999 and 0 <= l <= 99 and
start <= j < end }
sample point in desired but not implemented: start=1, end=2, i=0, k=0, j=1,
l=0
gist of constraints in implemented but not desired: [end, start] -> { [k,
l, j, i] : start <= i < end }
(see the gist for formatting)
However, if I change the order of the domains in the gist such that it goes
(i, j, k, l)---again, see the gist---the code generates correctly.
Is this a function of my not understanding how the domain / leaf structure
works? Or have I found a bug?
Nick