Hi Zhe Zhang,
I think Brad is on the money in his analysis of what we’ve done wrong here.
I’ve reduced your example to an even simpler test case and I believe I can
work to implement a fix. I’ll write again when I know more.
With regards,
Mike Noakes
On Jun 8, 2016, at 7:44 AM, Brad Chamberlain
<[email protected]<mailto:[email protected]>> wrote:
Hi Zhe Zhang --
If I'm understanding your example properly, Chapel is adding an extra argument
to the function call as a means of passing the return value out, is that right?
If so, this sounds like a bug to me. While the compiler does this for Chapel
functions (and should be permitted to I think), I don't think we should be
assuming we can manipulate external functions like this.
I expect it should be easy to stop the compiler from adding this additional
argument -- in particular, compiler/passes/returnStarTuplesByRefArg.cpp seems
like a likely candidate to short-circuit out of if the function has FLAG_EXTERN
on it. But then I wonder if there will be other problems that will prevent the
generated code from working...? What is the signature of your function in C?
Could you send us a full, but simple example demonstrating the issue to one of
the chapel-bugs mailing lists? (Or file it as a PR introducing a "future test"
against the test system if you're familiar with that procedure and have signed,
or can sign, a CLA?)
Thanks,
-Brad
________________________________
From: Zhe Zhang <[email protected]<mailto:[email protected]>>
Sent: Wednesday, June 8, 2016 1:31:07 AM
To:
[email protected]<mailto:[email protected]>
Subject: Extra parameter generated by chapel for extern C function
Hi
Chapel compiler generates extra parameter for certain extern C function calls.
For example:
require "immintrin.h";
extern type __m256 = 8*real(32);
extern proc _mm256_set_ps (in e7:real(32), in e6:real(32), in e5:real(32), in
e4:real(32), in e3:real(32), in e2:real(32), in e1:real(32), in e0:real(32)):
__m256;
proc main () {
var x: __m256;
x = _mm256_set_ps (1.0:real(32), 2.0:real(32), 3.0:real(32), 4.0:real(32),
5.0:real(32), 6.0:real(32), 7.0:real(32), 8.0:real(32));
}
This would cause an error:
error: too many arguments to function '_mm256_set_ps'
_mm256_set_ps(call_tmp_chpl9, call_tmp_chpl10, call_tmp_chpl11,
call_tmp_chpl12, call_tmp_chpl13, call_tmp_chpl14, call_tmp_chpl15,
call_tmp_chpl16, *(tmp_chpl));
^
/usr/lib/gcc/x86_64-pc-linux-gnu/4.9.3/include/avxintrin.h:1219:1: note:
declared here
_mm256_set_ps (float __A, float __B, float __C, float __D,
^
where _mm256_set_ps accepts 8 parameters in C, but an extra *(tmp_chpl) was
generated. If the implementation of __m256 was hiden from chapel:
extern type __m256;
extern proc _mm256_set_ps ...
It compiled fine, but then __m256 cannot be used as a tuple.
Is there a way to bypass the parameter generation and direct the extern
function to return a tupel/array as return value? And in what situation would
this behavior be triggered?
Thanks
Zhe Zhang
------------------------------------------------------------------------------
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are
consuming the most bandwidth. Provides multi-vendor support for NetFlow,
J-Flow, sFlow and other flows. Make informed decisions using capacity
planning reports.
https://ad.doubleclick.net/ddm/clk/305295220;132659582;e_______________________________________________
Chapel-users mailing list
[email protected]<mailto:[email protected]>
https://lists.sourceforge.net/lists/listinfo/chapel-users
------------------------------------------------------------------------------
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are
consuming the most bandwidth. Provides multi-vendor support for NetFlow,
J-Flow, sFlow and other flows. Make informed decisions using capacity
planning reports. https://ad.doubleclick.net/ddm/clk/305295220;132659582;e
_______________________________________________
Chapel-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/chapel-users
