Duncan,<br><br>Oh, right, now I remember: it's a very old problem I knew 1.5 years ago. There were even some bugs on it, here is a common case:<br><br>> cat test1.f90<br>program test<br><br> call test1()<br><br>end program test<br>
<br>> kernelgen-dragonegg test1.f90 -o- | opt -O3 -S -o -<br>; ModuleID = '<stdin>'<br>target datalayout = "e-p:64:64:64-S128-i1:8:8-i8:8:8-i16:16:16-i32:32:32-i64:64:64-f16:16:16-f32:32:32-f64:64:64-f128:128:128-v64:64:64-v128:128:128-a0:0:64-s0:64:64-f80:128:128-n8:16:32:64"<br>
target triple = "x86_64-unknown-linux-gnu"<br><br>@options.0.1537 = internal constant [8 x i32] [i32 68, i32 511, i32 0, i32 0, i32 0, i32 1, i32 0, i32 1], align 32<br><br>declare void @test1_(...)<br><br>define i32 @main(i32 %argc, i8** %argv) nounwind uwtable {<br>
entry:<br> tail call void @_gfortran_set_args(i32 %argc, i8** %argv) nounwind<br> tail call void @_gfortran_set_options(i32 8, i32* getelementptr inbounds ([8 x i32]* @options.0.1537, i64 0, i64 0)) nounwind<br> tail call void bitcast (void (...)* @test1_ to void ()*)() nounwind<br>
ret i32 0<br>}<br><br>declare void @_gfortran_set_args(i32, i8**)<br><br>declare void @_gfortran_set_options(i32, i32*)<br><br><br>So every external function call, not only flush, in DragonEgg is declared varargs and called with a bitcast. This is really really big problem in our case, because:<br>
<br>1) We need to convert calls to external functions to FFI invocation, i.e. catch all CallInsts-s, get function name, args' values and types. I don't know how to deal with CallInst-s that have bitcasts.<br>2) We can't have any varargs function defined in module, because it is operated by NVPTX, varargs are not allowed there.<br>
<br>How do you think what would be the best way to workaround this problem, if it seems to be not in focus for anybody for now?<br><br>Thanks,<br>- D.<br><br><div class="gmail_quote">2012/7/17 Duncan Sands <span dir="ltr"><<a href="mailto:baldrick@free.fr" target="_blank">baldrick@free.fr</a>></span><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Dmitry,<div class="im"><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Do you think this is a system problem of gcc applicable to other functions too, or just a flush-specific bug?<br>
</blockquote>
<br></div>
it has nothing to do with flush - for all I know flush is fine. Dragonegg<br>
does this for all Fortran functions because the Fortran front-end is so buggy,<br>
i.e. often produces wrong function types. I have another way of handling this<br>
in mind, which would avoid this trick, but I didn't get round to implementing<br>
it yet.<br>
<br>
Ciao, Duncan.<div class="HOEnZb"><div class="h5"><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Best,<br>
- Dima.<br>
<br>
----- Original message -----<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On 17/07/12 08:22, Anton Korobeynikov wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Dmitry,<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
This is probably a question for Fortran/DragonEGG experts:<br>
<br>
Why Fortran's "call flush()" is converted to "call void bitcast<br>
(void (...)* @_gfortran_flush_i4 to void (i8*)*)(i8* null) nounwind"<br>
? Why it needs bitcast?<br>
</blockquote>
Just a wild guess (basing from my llvm-gcc knwoledge though): there is<br>
a bug with in gcc fortran frontend where it fails to create the<br>
function TREEs with proper types. It might easily be possible that<br>
e.g. call of function with type with no args is performed with some<br>
amount of args, etc. It's pretty fine in gcc, but not in LLVM, the<br>
latter is much more strict wrt this.<br>
<br>
The only solution / workaround for this was to emit the function<br>
definition as variadic and do bitcast at a call site (there are some<br>
other fortran-specific stuff involved here, e.g dummy args)...<br>
<br>
See <a href="http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33097" target="_blank">http://gcc.gnu.org/bugzilla/<u></u>show_bug.cgi?id=33097</a> for more info.<br>
<br>
</blockquote>
<br>
Yes, this is the reason.<br>
<br>
Ciao, Duncan.<br>
______________________________<u></u>_________________<br>
LLVM Developers mailing list<br>
<a href="mailto:LLVMdev@cs.uiuc.edu" target="_blank">LLVMdev@cs.uiuc.edu</a> <a href="http://llvm.cs.uiuc.edu" target="_blank">http://llvm.cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev" target="_blank">http://lists.cs.uiuc.edu/<u></u>mailman/listinfo/llvmdev</a><br>
</blockquote>
<br>
</blockquote>
<br>
<br>
</div></div></blockquote></div><br>