<div dir="ltr">On Sun, Oct 19, 2014 at 6:54 AM, Anton Korobeynikov <span dir="ltr"><<a href="mailto:anton@korobeynikov.info" target="_blank">anton@korobeynikov.info</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I feel like opening a can full of worms here. Here is full story:<br>
<br>
1. On ARM all the EABI library functions need to use AAPCS calling<br>
convention even on hard floating point targets<br>
2. __mulsc3, __muldc3 and friends are not defined by EABI, however<br>
both compiler-rt and libgcc emit them with AAPCS, not AAPCS-VFP<br>
calling convention<br>
<br>
Right now clang creates calls to __mul?c3 routines, but uses C calling<br>
convention, which on hard FP targets got translated into AAPCS-VFP CC,<br>
which is certainly not what the implementation expects.<br>
<br>
The obvious fix is to make sure clang specifies proper calling<br>
convention for such calls. And here we have plenty of funny details.<br>
<br>
1. There is CodeGenModule::CreateRuntimeFunction() which is used to<br>
emit calls to runtime functions. Surely, we cannot use it here,<br>
because we would not like to force calling convention on routines like<br>
__cxa_throw, etc. (while they are not using and FP arguments and<br>
technically it's safe for ARM, but...)<br>
2. Even more CodeGenModule::CreateRuntimeFunction() itself is not<br>
enough. The reason is that we need to specify a calling convention on<br>
*both* call and function.  Usually we're using<br>
CodeGenFunction::EmitRuntimeCall() simply because creating a function<br>
requires one to specify LLVM calling convention and<br>
CodeGenFunction::CreateCall() expects clang's calling convention ;)<br>
3. So, for now I decided to separate calling conventions used to emit<br>
calls to runtime functions and compiler builtins.<br>
<br>
Some patch which shows this approach (and the whole problem) is attached :)</blockquote><div><br></div><div>I think I would agree with Tim on this.  The intrinsic approach would be nicer.  The actual calling convention and function name information is handled in the lowering, and even correctly switches between various ones.  This also affords us flexibility in the various functions the target runtime library supports.  The alternative would be to hoist that knowledge in clang, but that would be problematic for cases of JIT.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">
On Sat, Oct 18, 2014 at 3:27 PM, Anton Korobeynikov<br>
<<a href="mailto:anton@korobeynikov.info">anton@korobeynikov.info</a>> wrote:<br>
> Hi Chandler,<br>
><br>
> That's embarrassing how weird this part of clang is. I have a provisional<br>
> patch which fixes the problem but underlines clang's problems. I will submit<br>
> it tonight for comments.<br>
><br>
> суббота, 18 октября 2014 г. пользователь Chandler Carruth написал:<br>
><br>
>><br>
>> On Fri, Oct 17, 2014 at 7:51 AM, Anton Korobeynikov<br>
>> <<a href="mailto:anton@korobeynikov.info">anton@korobeynikov.info</a>> wrote:<br>
>>><br>
>>> > Chandler’s complex arithmetic changes are also in the range: r219557 in<br>
>>> > clang.  We saw it change the code in mandel-2 significantly.<br>
>>> mandel-2 is broken on hard FP ABI systems, btw. The reason is simply:<br>
>>> we're emitting a call to __muldc3 with AAPCS VFP calling convention,<br>
>>> however, the function expects softfp (AAPCS) calling conv and reads<br>
>>> garbage from GP registers.<br>
>>><br>
>>> I'm working on fix.<br>
>><br>
>><br>
>> Thanks for looking at this Anton.<br>
>><br>
>> I don't really know what signal should be used here. Several initial<br>
>> attempts at this didn't work because of ABI and calling convention issues<br>
>> and I thought I had figured out a sound solution by directly forming and<br>
>> calling the library routines using Clang's code generation to handle all of<br>
>> the ABI issues.... but apparently not.<br>
>><br>
>> If you need to back out the patch temporarily or take any other steps to<br>
>> mitigate, by all means. =/ Sorry for the fallout.<br>
><br>
><br>
><br>
> --<br>
> With best regards, Anton Korobeynikov<br>
> Faculty of Mathematics and Mechanics, Saint Petersburg State University<br>
><br>
<br>
<br>
<br>
--<br>
With best regards, Anton Korobeynikov<br>
Faculty of Mathematics and Mechanics, Saint Petersburg State University<br>
</div></div><br>_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:LLVMdev@cs.uiuc.edu">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/mailman/listinfo/llvmdev</a><br>
<br></blockquote></div><br><br clear="all"><div><br></div>-- <br>Saleem Abdulrasool<br>compnerd (at) compnerd (dot) org
</div></div>