Re: [gfortran,patch] Inline remaining allocation/deallocation routines

["Richard Guenther" <richard dot guenther at gmail dot com>]

On 8/28/07, Tobias Burnus <burnus@net-b.de> wrote:
> Richard Guenther wrote:
> > On 8/28/07, François-Xavier Coudert <fxcoudert@gmail.com> wrote:
> >
> >>> By the way, somehow the middle end fails to optimize away the "if(a.data
> >>> != NULL)" branch although the variable has been initialized to NULL
> >>> before. With my little C program it works (even w/o using the "restrict"
> >>> attribute). We should fill a middle end PR when this is checked in.
> >>>
> > I guess that 'a' is a global?  (Do you have a fortran testcase that shows this?)
> >
>
> I assume in the following that FX's patch has been applied.
>
> ------------ (a) --------------------
> integer, allocatable :: a(:),b(:)
> allocate(a(5),b(5))
> end
> -------------------------------------
>
>
> The problem presumably is the "_gfortran_os_error()" call inbetween. Is
> there the possibility to set the pointers "a" and "b" as "restrict"ed?
> Fortran standard mandates that to an allocatable array, a pointer only
> may point to when it is marked as TARGET. (I don't know whether
> front-end generated code aliases, I think it does not.)
>
> Additionally, is there the possibility to mark the
> "_gfortran_os_error()" as a routine having no side effects - or in this
> special case - as not returning?

I see we produce (with -O):

<bb 2>:
  _gfortran_set_options (7, &options.0);
  D.1383 = __builtin_malloc (20);
  if (D.1383 == 0B)
    goto <bb 3>;
  else
    goto <bb 4>;

<bb 3>:
  _gfortran_os_error (&"Out of memory"[1]{lb: 1 sz: 1});

<bb 4>:
  D.1385 = __builtin_malloc (20);
  if (D.1385 == 0B)
    goto <bb 5>;
  else
    goto <bb 6>;

<bb 5>:
  _gfortran_os_error (&"Out of memory"[1]{lb: 1 sz: 1});

<bb 6>:
  __builtin_free (D.1383);
  __builtin_free (D.1385) [tail call];
  return;

which looks ok.  The above could use the same call to _gfortran_os_error though,
by making the function pure.  Though at the tree level no optimization would do
this transformation leaving only possibly rtl cross-jumping to do
this, but I have
no idea if that can exploit the no-return and the pureness of calls ;)

Richard.