Segmentation fault

[Akilesh]

#pragma scop
    for (int l = 0; l < 50; l += 1) {
        for (int m = 0; m < 64; m += 1) {
            for (int n = 0; n < 8; n += 1) {
                for (int p = 0; p < 8; p += 1) {
                    for (int i = 0; i < 16; i += 1) {
                        for (int j = 0; j < 5; j += 1) {
                            for (int k = 0; k < 5; k += 1) {
                                A[l][(i * 1)][(j * 1 + n)][(k * 1 + p)] += B[l][m][n][p] * C[m][i][j][k];
                            }
                        }
                    }
                }
            }
        }
    }
#pragma endscop

When I run the above portion of code using Pluto using: time ./polycc <above_file.c> --tile --parallel, I get segmentation fault: ./polycc: line 54: 11546 Segmentation fault      (core dumped) $pluto $*

Could you please provide some suggestions on overcoming this?

Thanks
Akilesh

[Uday R Bondhugula]

On 20-03-2017 20:36, 'Akilesh' via Pluto development wrote:
> #pragma scop
> for (int l = 0; l < 50; l += 1) {
> for (int m = 0; m < 64; m += 1) {
> for (int n = 0; n < 8; n += 1) {
> for (int p = 0; p < 8; p += 1) {
> for (int i = 0; i < 16; i += 1) {
> for (int j = 0; j < 5; j += 1) {
> for (int k = 0; k < 5; k += 1) {
> A[l][(i * 1)][(j * 1 + n)][(k * 1 +
> p)] += B[l][m][n][p] * C[m][i][j][k];
> }
> }
> }
> }
> }
> }
> }
> #pragma endscop
>

> When I run the above portion of code using Pluto using: TIME ./POLYCC
> <ABOVE_FILE.C> --TILE --PARALLEL, I get segmentation fault: ./polycc:

> line 54: 11546 Segmentation fault (core dumped) $pluto $*
>
> Could you please provide some suggestions on overcoming this?

Please add --lastwriter to the flags to overcome this for now. The small
constant bounds combined with the deep loop nest make Pluto run out of
memory - the constraints explode here. Alternatively, if you had used
parametric bounds (P1 = 50, P2 = 64, ..., and then used P1, P2, ...,),
this problem won't arise even without lastwriter. Thank you for
reporting this, although I have run into these cases before. A different
farkas multiplier elimination scheme (which isn't currently in the
public git but in our internal version) doesn't suffer from this problem
with or without lastwriter. The public git will brought up to speed on
this soon.

Now, even with --lastwriter, you'll see transformations like:

T(S1): (l, i, n+j, p+k, m, 4m+n, 20m+4n+p)

The large skews are all spurious and undesirable - this is again a
side-effect of using small constant trip counts. The problem can be
circumvented by using parametric bounds as mentioned above, or with
--coeff-bound=1 (an undocumented option that upper bounds transformation
coefficients by 1).

~ Uday

>
> Thanks
> Akilesh
>
> --
> You received this message because you are subscribed to the Google
> Groups "Pluto development" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to pluto-developm...@googlegroups.com.
> To post to this group, send email to
> pluto-de...@googlegroups.com.
> Visit this group at MAILSCANNER HAS DETECTED DEFINITE FRAUD IN THE
> WEBSITE AT "GROUPS.GOOGLE.COM". DO _NOT_ TRUST THIS WEBSITE:
> https://groups.google.com/group/pluto-development [1].
> For more options, visit MAILSCANNER HAS DETECTED DEFINITE FRAUD IN THE
> WEBSITE AT "GROUPS.GOOGLE.COM". DO _NOT_ TRUST THIS WEBSITE:
> https://groups.google.com/d/optout [2].
>
> --
> This message has been scanned for viruses and
> dangerous content by MAILSCANNER [3], and is
> believed to be clean.
>
> Links:
> ------
> [1] https://groups.google.com/group/pluto-development
> [2] https://groups.google.com/d/optout
> [3] http://www.mailscanner.info/

[Abhishek Patwardhan]

Hi,
Thank you sir for this information.

Thanks and Regards,
= Abhishek.

an email to pluto-development+unsubscribe@googlegroups.com.

To post to this group, send email to

pluto-development@googlegroups.com.

[Sven Verdoolaege]

On Mon, Mar 20, 2017 at 10:23:14PM +0530, Uday K Bondhugula wrote:
> Now, even with --lastwriter, you'll see transformations like:
>
> T(S1): (l, i, n+j, p+k, m, 4m+n, 20m+4n+p)
>
> The large skews are all spurious and undesirable - this is again a
> side-effect of using small constant trip counts. The problem can be
> circumvented by using parametric bounds as mentioned above, or with
> --coeff-bound=1 (an undocumented option that upper bounds transformation
> coefficients by 1).

FYI, it may be useful to derive bounds on the coefficients
from the size of the domain. That's what I do in isl and
in fact this example helped to refine the strategy.
It's described in Section 7.5 Loop Coalescing Avoidance
of Scheduling for PPCG.

With --no-isl-schedule-treat-coalescing, the resulting schedule
is very similar to the one you show above:

domain: "{ S_0[l, m, n, p, i, j, k] : 0 <= l <= 49 and 0 <= m <= 63 and 0 <= n <= 7 and 0 <= p <= 7 and 0 <= i <= 15 and 0 <= j <= 4 and 0 <= k <= 4 }"
child:
schedule: "[{ S_0[l, m, n, p, i, j, k] -> [(l)] }, { S_0[l, m, n, p, i, j, k] -> [(n + j)] }, { S_0[l, m, n, p, i, j, k] -> [(p + k)] }, { S_0[l, m, n, p, i, j, k] -> [(i)] }, { S_0[l, m, n, p, i, j, k] -> [(m)] }, { S_0[l, m, n, p, i, j, k] -> [(4m + n)] }, { S_0[l, m, n, p, i, j, k] -> [(20m + 4n + p)] }]"
permutable: 1
coincident: [ 1, 1, 1, 1, 0, 0, 0 ]

Without the option, a bound of "2" is derived from the domain size
and the following schedule is produced:

domain: "{ S_0[l, m, n, p, i, j, k] : 0 <= l <= 49 and 0 <= m <= 63 and 0 <= n <= 7 and 0 <= p <= 7 and 0 <= i <= 15 and 0 <= j <= 4 and 0 <= k <= 4 }"
child:
schedule: "[{ S_0[l, m, n, p, i, j, k] -> [(l)] }, { S_0[l, m, n, p, i, j, k] -> [(n + j)] }, { S_0[l, m, n, p, i, j, k] -> [(p + k)] }, { S_0[l, m, n, p, i, j, k] -> [(i)] }, { S_0[l, m, n, p, i, j, k] -> [(m)] }]"
permutable: 1
coincident: [ 1, 1, 1, 1, 0 ]
child:
schedule: "[{ S_0[l, m, n, p, i, j, k] -> [(n)] }]"
child:
schedule: "[{ S_0[l, m, n, p, i, j, k] -> [(p)] }]"

That is, the last two loops have been split off from the tilable band
due to the bounds on the coefficients.

Note that for reliable results, you need isl-0.18-768-g033b61ae3d
or higher.

skimo