Re: PR 35681: Correct handling of "expressions" with ELEMENTAL subroutines

["Paul Richard Thomas" <paul dot richard dot thomas at gmail dot com>]

Daniel,

>>> ELEMENTAL call and thus only scalar temporaries are created one at a time
>>> and not one array temporary, as it should be.
>>
>> This is why I translated the temporary creation the way that I did.
>
> I don't get your point here, it seems...  Do you think the scalar temporary
> is better because it imposes no/not so much performance cost?

No, no!  I wrote gfc_conv_elemental_dependencies the way that I did
exactly to get round the problem of the scalar temporary creation.  I
could not see an easier way to do it.

>
>>> Currently there's already logic to handle temporaries (although for the
>>> INTENT(OUT) arguments) if required for ELEMENTAL calls
>>> (trans-stmt.c:gfc_conv_elemental_dependencies) and I tried to study the
>>> code
>>> there, but unfortunatelly am not really an expert about trans-time
>>> scalarization and all those ss/se things.
>>
>> The testcase in this PR never exercises this bit of code because the
>> resolved_symbol for MVBITS never gets formal arguments.  A very good
>> start would be to fix this.  In addition, you would have to detect
>> that MVBITS is being handled by trans-call in order to call
>> gfc_conv_elemental_dependencies.  This is because MVBITS is the
>> exception to the rule about allowing arguments to an elemental
>> subroutine that can alias.
>
> I'm not sure what gfc_conv_elemental_dependencies is really for, and I know
> it does not get called; but I hoped to find guidance on how I can do my own
> temporaries, but didn't really find what I was looking for (at least, didn't
> quite understand every detail so it would be useful).

It is specifically for the case of interface assignment and ensures
that a temporary is written if there is a dependency between the lhs
(INTENT(OUT)) and the rhs (INTENT(IN)).  It can, however, be hijacked
for MVBITS.

>
> Actually, at the moment I'm  not looking at MVBITS but at ELEMENTAL
> subroutines in general.  As written in the PR (I hope I did so), I believe
> my copy-test from comment #7 (IIRC) is valid and mis-compiled if parentheses
> are added around the first argument (so it is an expression as in Dick's
> example, but without MVBITS).  I hope I didn't get this wrong and it is
> still invalid.  I believe the problem here is that the expression is
> evaluated in already scalarized form and that the standard requires an array
> temporary and thus not the behaviour you mentioned above (well, at least
> that the program behaves as if there was an array temporary).  Or is this
> wrong?
>

Indeed, this

  integer, dimension (2) :: xx, yy
  xx = [1,2]
  call foo ((xx([2,1])), yy)
  yy = bar ((xx([2,1])))
contains
  elemental subroutine foo (a1, a2)
    integer, intent(in) :: a1
    integer, intent(out) :: a2
    a2 = 2*a1
  end subroutine
  elemental integer function bar (a1)
     integer, intent(in) :: a1
     bar = 2*a1
  end function
end

does not produce a temporary for the subroutine or the function
call...... but then neither does g95.  That said, g95 does the right
thing with the original testcase with mvbits!

I have to confess that I am now confused about the effect of
parentheses on elemental procedure arguments.

I think that it's one for clf.

>
> What's about, for instance for a numeric vector x, "x + 0"?  Wouldn't this
> also require a temporary just as parentheses would?  But my main problem was
> that I didn't even get the parentheses temporary work, because the way it is
> done in gfc_conv_elemental_dependencies relies on an ss_info-structure (or
> something like that) which is there for EXPR_VARIABLE's but seems to be
> missing for EXPR_OP's.  But maybe this can be fixed?  But this once again
> would probably be a quite intrusive change.

This would not ordinarily need a temporary, except for MVBITS when
there is a dependency.

Cheers

Paul

-- 
The knack of flying is learning how to throw yourself at the ground and miss.
       --Hitchhikers Guide to the Galaxy