added OpenCL ref_type

[t4c1]

Summary

Added reference (ref_type) for kernel generator expressions.

ref_type_for_opencl_test.cpp is not a new file; it has been renamed from ref_type_test.cpp.

Tests

Added tests for OpenCL ref_type.

Side Effects

None.

Release notes

Added reference (ref_type) for kernel generator expressions.

Checklist

• Math issue #(issue number)

• Copyright holder: Tadej Ciglarič

  The copyright holder is typically you or your assignee, such as a university or company. By submitting this pull request, the copyright holder is agreeing to the license the submitted work under the following licenses:
  - Code: BSD 3-clause (https://opensource.org/licenses/BSD-3-Clause)
  - Documentation: CC-BY 4.0 (https://creativecommons.org/licenses/by/4.0/)

• the basic tests are passing

  • unit tests pass (to run, use: ./runTests.py test/unit)
  • header checks pass, (make test-headers)
  • dependencies checks pass, (make test-math-dependencies)
  • docs build, (make doxygen)
  • code passes the built in C++ standards checks (make cpplint)

• the code is written in idiomatic C++ and changes are documented in the doxygen

• the new changes are tested

[bbbales2]

Looks good. One test suggestion

[bbbales2]

[optional] Only suggestion I here is that for each one of these just do a double check test:

EXPECT_TRUE(std::is_same<calc_if_<false, T1>, the_other_expected_type>::value);
EXPECT_TRUE(std::is_same<calc_if_<true, T2>, the_expected_type>::value);

So don't worry about the reference behavior or checking values (current tests cover that) -- just check the type calculations.

I guess these things are trivially true here in the code but if something broke in the future it would be easier to figure it out with an explicit test than reverse engineering it from wherever it does break.

[t4c1]

Half of these definitions are recursive - the value depends on child expression. Also types listed here are just ones that can be trivial. There are many other expressions that can not be trivial. So I think writing tests for ~100 different cases is not worth it, given how simple the implementation is.

[stan-buildbot]

---

Name	Old Result	New Result	Ratio	Performance change( 1 - new / old )
gp_pois_regr/gp_pois_regr.stan	3.45	3.41	1.01	1.11% faster
low_dim_corr_gauss/low_dim_corr_gauss.stan	0.02	0.02	0.99	-0.88% slower
eight_schools/eight_schools.stan	0.11	0.12	0.98	-2.15% slower
gp_regr/gp_regr.stan	0.16	0.16	1.01	0.59% faster
irt_2pl/irt_2pl.stan	5.27	5.28	1.0	-0.08% slower
performance.compilation	91.48	89.0	1.03	2.71% faster
low_dim_gauss_mix_collapse/low_dim_gauss_mix_collapse.stan	8.62	8.71	0.99	-1.11% slower
pkpd/one_comp_mm_elim_abs.stan	28.92	29.61	0.98	-2.39% slower
sir/sir.stan	136.88	132.64	1.03	3.1% faster
gp_regr/gen_gp_data.stan	0.04	0.04	0.96	-4.51% slower
low_dim_gauss_mix/low_dim_gauss_mix.stan	3.0	2.98	1.01	0.52% faster
pkpd/sim_one_comp_mm_elim_abs.stan	0.39	0.38	1.02	1.7% faster
arK/arK.stan	1.79	1.8	0.99	-0.51% slower
arma/arma.stan	0.75	0.75	1.0	0.02% faster
garch/garch.stan	0.57	0.58	0.99	-1.32% slower
Mean result: 0.998239586787

---

Jenkins Console Log
Blue Ocean
Commit hash: 1e1bd58

---

Machine information

ProductName: Mac OS X ProductVersion: 10.11.6 BuildVersion: 15G22010

CPU:
Intel(R) Xeon(R) CPU E5-1680 v2 @ 3.00GHz

G++:
Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr --with-gxx-include-dir=/usr/include/c++/4.2.1
Apple LLVM version 7.0.2 (clang-700.1.81)
Target: x86_64-apple-darwin15.6.0
Thread model: posix

Clang:
Apple LLVM version 7.0.2 (clang-700.1.81)
Target: x86_64-apple-darwin15.6.0
Thread model: posix