On Tue, Aug 3, 2021 at 9:31 PM Martin Uecker <muec...@gwdg.de> wrote:
>
> Am Dienstag, den 03.08.2021, 11:26 +0200 schrieb Richard Biener:
> > On Tue, Aug 3, 2021 at 10:28 AM Martin Uecker <muec...@gwdg.de> wrote:
>
>
> >
> > Does the same issue arise with writing the testcases as
> >
> > ({ ... }) + i;
> >
> > ? How can we fix it then if you also need to support
> >
> > i + ({ ...});
> >
> > ?
>
> Here, the FE always moves the pointer to the right and
> then produces something like:
>
> *((int *) TARGET_EXPR <D.1952, {
> int n = 10;
> ...
> D.1952 = x;
> }> + ((sizetype) SAVE_EXPR <n> + 1) * 20);
>
>
> So these are the cases which already work without
> the path, although maybe it is wrong to have
> the n in the SAVE_EXPR?
>
> It gets gimplified to something like this,
> which works:
>
> int[0:D.1959][0:D.1955] * D.1952;
> int n.0;
> sizetype D.1955;
> sizetype D.1959;
>
> {
> int n;
> int[0:D.1959][0:D.1955] * x;
>
> n = 10;
> n.0 = n;
>
> ...
>
> _32 = (sizetype) n.0;
> _33 = (sizetype) n.1;
> _34 = _32 * _33;
> _35 = _34 * 4;
> x = __builtin_malloc (_35);
> D.1952 = x;
> }
> _36 = (sizetype) n.0;
> _37 = _36 + 1;
> _38 = _37 * 20;
> _39 = D.1952 + _38;
>
>
> For the array ref, the FE produces:
>
>
> (*TARGET_EXPR <D.1951, {
> int n = 10;
> ...
> D.1951 = x;
> }>)[5][5];
>
>
> With the patch, we get something like
> the following in GIMPLE, which seems correct:
>
> int[0:D.1958][0:D.1954] * D.1951;
> int n.0;
> sizetype D.1954;
>
> {
> int n;
> int[0:D.1958][0:D.1954] * x;
>
> n = 10;
> n.0 = n;
>
> _7 = (sizetype) n.0;
> _8 = _7 * 4;
> D.1956 = _8;
>
> n.1 = n
>
> _22 = (sizetype) n.0;
> _23 = (sizetype) n.1;
> _24 = _22 * _23;
> _25 = _24 * 4;
> x = __builtin_malloc (_25);
> D.1951 = x;
> }
> _26 = D.1956 /[ex] 4;
> c = (*D.1951)[5]{lb: 0 sz: _26 * 4}[5];
OK, thanks for the try to explaining.
I think the patch makes sense but the comment says
Java requires that we elaborated nodes in source order. That
means we must gimplify the inner expression followed by each of
the indices, in order. But we can't gimplify the inner
expression until we deal with any variable bounds, sizes, or
positions in order to deal with PLACEHOLDER_EXPRs.
and I don't really understand that (not to say Java is no longer supported
by GCC, but Ada does use PLACEHOLDER_EXPRs). In fact the comment
suggests that we _should_ gimplify the inner expression first ... at least it
seems to after your explanations ;)
Eric - do you know anything about this?
Martin - I think the patch is OK but please make sure to bootstrap & regtest
with all languages enabled (--enable-languages=all) and make sure you
have an Ada host compiler installed so you get Ada included as well.
Thanks,
Richard.
>
> MArtin
>
