User requested specializations don't work on functions behind object wrappers
|
|
Bugzilla Link |
1180 |
Created on |
May 17, 2016 17:43 |
Version |
svn |
OS |
Linux |
Architecture |
PC |
Extended Description
A user can request a function to be specialized for certain input data by using the specialize directive:
specialize double[100,100,100] foo (double[100,100,100] A);
This would instruct sac2c to create a specialized version of the function foo() that gets a 100x100x100 array as input.
For "simple" functions this works fine, but when you use modules from stdlib inside foo(), the objects holding the functions used are being passed as hidden arguments to the function foo(), in front of the declared arguments. So if for example you'd user timers to measure the execution duration of something inside foo(), the function signature would internally be rewritten to look like this:
RTClock::RTClock double[100,100,100] foo( RTClock::RTClock _rso_11_TheRTClock { ,NN }, double[100,100,100] A { ,NN })
If foo() is declared within the module the specialize directive is in, this too works just fine.
However, if foo() is imported, sac2c generates an object wrapper around it (ptc:gon). This happens before we generate specializations (tc:esp). As a consequence, when trying to determine the best function to use for generating the specialization (at least I believe that is what TYdispatchFunType() does) we pick the generated object wrapper instead of the real foo(), and subsequently generate a specialization of that object wrapper, which is pretty useless and definitely not what the user intended.