| Jugoslav Dujic 2006-01-10, 9:58 pm |
| Paul Van Delst wrote:
| Jugoslav Dujic wrote:
||
|| Note that James's test program is not closely related to that issue --
|| namely, with assumed-shape dummy and a non-contiguous array section
|| (excluding vector subscripted ones, which I anyway count as an "expression"
|| in my book) as real argument, a copy *never* has to be made. A compiler
|| might do that for performance reasons (although it more often degrades
|| performance than not)...
||
|| Still, it seems the simple case of passing contiguous
||| array slices/subsets, or regularly strided array triplets, as actual
||| arguments will generate a copy "by default" in xlf. I used the quotes since
||| the optimisation opportunity of handling these arguments in a more, uh,
||| sophisticated manner was acknowledged followed by the statement that it
||| hasn't been done yet. So there would appear to be no switch to turn this
||| behaviour off.
||
|| ...rather, I think that XLF always copies array subsets when they
|| match an *assumed-size* dummy.
|
| I'm not sure I understand your use of the word "rather" (i..e. agreeing or
| disagreeing) and the assumed-size reference. So let me re-iterate.
I'm not sure I do too -- it was a mis-reference to another sentence :o)
| Correctly or not, I always assumed (no pun) that an assumed /size/ dummy arg
| generated a copy when an array subset/triplet was passed as an actual arg. I
| have no problem with that since, if I understand things correctly, there is
| no "extra" information passed that would allow one to use the SIZE() and/or
| SHAPE() intrinsics on the assumed /size/ dummy arg and, thus, there would
| also be no "extra" information available that would allow the compiler to
| generate code to access the data in question via a reference+amount of
| data+stride. E.g. the following code, subroutine assumedsize( a )
| real :: a(*)
| print *, shape(a)
| end subroutine assumedsize
| won't compile (at least, not on any compiler I've ever used)
|
| But, my question to the IBM people was when an array subset/triplet actual
| arg was passed to a subprogram with an assumed /shape/ dummy arg. In this
| case, there is that "extra" info available, e.g. the code
| subroutine assumedshape( a )
| real :: a(:)
| print *, shape(a)
| end subroutine assumedshape
| is fine. The response I got tells me that even in those cases, xlf generates
| a copy.
Sorry, but I didn't figure that out from the context. I thought the question
was related with assumed-size dummies. Now that you specify it's assumed-shape,
the behavior as stated does not make much sense to me. Yes, it is (seems?)
possible,
but it IMO would be a lousy quality of implementation; for a . Are you *sure*
you
understood each other right? It's quite easy to make a size/shape mixup. As
you said, it passes James's test OK, so it makes me wonder....
To summarize:
1)If XLF always passes a copy for a stride or triplet even for assumed-shape
target, that's quite unusual (and would be lousy). That would mean that
they didn't implement "dope vectors" at all, but just somehow retrofitted
assumed-shape into assumed-size semantics. That would also mean that they
had to special-case James's test somehow.
2)If XLF always passes a copy for a stride or triplet for assumed-size argument,
that's acceptable, if somewhat lazy way of doing it.
But why don't you try case(1) for yourself -- you just have to figure out
how to get address of RealArgArray(1) and DummyArgArray(1) with a LOC()
extension or call to C routine?
--
Jugoslav
___________
www.xeffort.com
Please reply to the newsgroup.
You can find my real e-mail on my home page above.
|