You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The UPCR spec includes the upcr_{shared,pshared1,psharedI}_inc() interfaces which take a pointer-to-shared by reference and add to it a signed integral value. This was intended for code generation for the following constructs (where p is an lvalue of pointer-to-shared type and i is an expression with some integral type):
p++ and p--
++p and --p
p += i
p -= i
Currently the Berkeley UPC translator does not use any of these interfaces, instead generating calls to upcr_{shared,pshared1,psharedI}_add() just as clang-upc2c is doing. However, the inc interfaces should never be less efficient than the add ones and in the two phaseless cases the inc is much more efficient. So, the Berkeley translator's failure to use inc when appropriate in is (bug 224)[https://upc-bugs.lbl.gov/bugzilla/show_bug.cgi?id=224].
So, this issue is the clang-upc analog to BUPC's bug 244 - requesting generation of calls to the PTS increment interfaces when appropriate.
As was observed when reducing spills for Load and Store one needs to take care with the case that the lvalue has side-effects and when it is volatile. The current code for p+=n; ++p; p--; is (except for the reuse of the spills below):
[Noting that the same code is generated regardless of the volatility of p, the code for p-- appears incorrect for the volatile case because it reads the value twice. Of course that issue it independent of this one.]
However, I would consider the removal of the spill secondary to the switch from add to inc since I suspect any decent back-end compiler can eliminate the (single-assignment) temporary.
I will create an issue for the volatile post-inc/dec bug shortly...
The text was updated successfully, but these errors were encountered:
Those will probably remain the code for volatile pointers-to-shared.
While the pre-(inc|dec)rement can be simplified slightly by removal of the final , _bupc_spilld1 that is also an optimization the back-end can be expected to perform.
Some tests I performed related to this issue showed no noticeable benefit for using the "inc" operations with the packed PTS. The benefit for the struct PTS rep will probably depend on whether the target ABI passes the struct in register(s) or memory.
The UPCR spec includes the
upcr_{shared,pshared1,psharedI}_inc()
interfaces which take a pointer-to-shared by reference and add to it a signed integral value. This was intended for code generation for the following constructs (wherep
is an lvalue of pointer-to-shared type andi
is an expression with some integral type):p++
andp--
++p
and--p
p += i
p -= i
Currently the Berkeley UPC translator does not use any of these interfaces, instead generating calls to
upcr_{shared,pshared1,psharedI}_add()
just as clang-upc2c is doing. However, theinc
interfaces should never be less efficient than theadd
ones and in the two phaseless cases theinc
is much more efficient. So, the Berkeley translator's failure to useinc
when appropriate in is (bug 224)[https://upc-bugs.lbl.gov/bugzilla/show_bug.cgi?id=224].So, this issue is the clang-upc analog to BUPC's bug 244 - requesting generation of calls to the PTS increment interfaces when appropriate.
As was observed when reducing spills for Load and Store one needs to take care with the case that the lvalue has side-effects and when it is volatile. The current code for
p+=n; ++p; p--;
is (except for the reuse of the spills below):[Noting that the same code is generated regardless of the volatility of
p
, the code forp--
appears incorrect for the volatile case because it reads the value twice. Of course that issue it independent of this one.]The expected most general replacements could be:
[Where the last line is still wrong for volatile
p
].In the (probably most-common) case that the lvalue is non-volatile and is free of side-effects, one might eliminate the pointer spills:
However, I would consider the removal of the spill secondary to the switch from
add
toinc
since I suspect any decent back-end compiler can eliminate the (single-assignment) temporary.I will create an issue for the volatile post-inc/dec bug shortly...
The text was updated successfully, but these errors were encountered: