Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Inefficient PTS increments (++,--,+=,-=) #87

Open
PHHargrove opened this issue Mar 22, 2014 · 2 comments
Open

Inefficient PTS increments (++,--,+=,-=) #87

PHHargrove opened this issue Mar 22, 2014 · 2 comments

Comments

@PHHargrove
Copy link
Contributor

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):

(_bupc_spilld0 = &(p) , *_bupc_spilld0 = upcr_add_psharedI(*_bupc_spilld0, 4UL, n));
(_bupc_spilld0 = &p , *_bupc_spilld0 = upcr_add_psharedI(*_bupc_spilld0, 4UL, 1) , *_bupc_spilld0);
(_bupc_spilld0 = &p , _bupc_spilld1 = *_bupc_spilld0 , *_bupc_spilld0 = upcr_add_psharedI(*_bupc_spilld0, 4UL, -1) , _bupc_spilld1);

[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.]

The expected most general replacements could be:

(_bupc_spilld0 = &p, upcr_inc_psharedI(_bupc_spilld0, 4UL, n), *_bupc_spilld0);
(_bupc_spilld0 = &p, upcr_inc_psharedI(_bupc_spilld0, 4UL, 1) , *_bupc_spilld0);
(_bupc_spilld0 = &p, _bupc_spilld1 = *_bupc_spilld0 , upcr_inc_psharedI(_bupc_spilld0, 4UL, -1) , _bupc_spilld1);

[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:

(upcr_inc_psharedI(*p, 4UL, n), p);
(upcr_inc_psharedI(&p, 4UL, 1) , p);
(_bupc_spilld1 = p , upcr_inc_psharedI(&p, 4UL, -1) , _bupc_spilld1);

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...

@PHHargrove
Copy link
Contributor Author

The incorrect-for-volatile bug (issue #88) has been fixed.
The new code for post-dec and pre-inc respectively:

(_bupc_spilld0 = &p , _bupc_spilld1 = *_bupc_spilld0 , *_bupc_spilld0 = upcr_add_pshared1(_bupc_spilld1, 4UL, -1) , _bupc_spilld1)
(_bupc_spilld0 = &p , _bupc_spilld1 = upcr_add_pshared1(*_bupc_spilld0, 4UL, 1) , *_bupc_spilld0 = _bupc_spilld1 , _bupc_spilld1)

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.

@PHHargrove
Copy link
Contributor Author

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant