llvm dev - Sep 2014 - [LLVMdev] [Compiler-RT] [ARM] Where __aeabi_[il]div0 builtins should be implemented?

On Fri, Sep 5, 2014 at 11:32 AM, Jonathan Roelofs <jonathan at
codesourcery.com
> wrote:
> Sergey,
>
> Not that it'll save you much hassle, but here's an implementation
of
> __aeabi_idiv0 and __aeabi_ldiv0 that I've been sitting on for a while.
>
> I vaguely remember compnerd suggesting that I don't commit them to
> compiler_rt, but I don't remember why.
>
I did dig into this further and it seems that they are, in fact, considered
part of the RT-ABI :-(.  Ive committed a simple conforming implementation
in SVN r217322.

>
> Cheers,
>
> Jon
>
>
> On 9/5/14, 12:10 PM, Sergey Dmitrouk wrote:
>
>> Hi,
>>
>> There are several places in compiler-rt which refer to __aeabi_idiv0.
>> For example, in lib/builtins/arm/udivsi3.S:
>>
>> #ifdef __ARM_EABI__
>>      b __aeabi_idiv0
>> #else
>>      JMP(lr)
>> #endif
>>
>> At the same time there is no definition of it.  It looks as if it was
>> done intentionally so that third-party could provide custom handler for
>> division by zero.
>>
>> IMHO It's not very consistent and looks odd as all other __aebi_*
>> functions are provided by compiler-rt.
>>
>> Did I get it all right or maybe I'm missing something?
>>
>> libgcc provides both __aeabi_idiv0 and __aeabi_ldiv0 as weak symbols,
>> any reasons not to do the same in compiler-rt?  Or, to put it
>> differently, why force external implementation of these functions?
>>
>> Thanks,
>> Sergey
>> _______________________________________________
>> LLVM Developers mailing list
>> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>>
>>
> --
> Jon Roelofs
> jonathan at codesourcery.com
> CodeSourcery / Mentor Embedded
>


-- 
Saleem Abdulrasool
compnerd (at) compnerd (dot) org
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20140906/314dc41d/attachment.html>

On 6 September 2014 22:46, Saleem Abdulrasool <compnerd at compnerd.org>
wrote:
> I did dig into this further and it seems that they are, in fact, considered
> part of the RT-ABI :-(.  Ive committed a simple conforming implementation
in
> SVN r217322.
Hi Saleem,

This implementation will differ from the current sdiv's expected
(return 0) if called from a place that doesn't mov r0, #0 just before
calling div0.

ARM and GCC both throw an exception, and on non-EABI ARM, we're
returning zero, so it would be good to have at least one consistent
behaviour.

I think we should return zero on both idiv0 and ldiv0 and move the
"mov r0, #0" inside the #else for now.

cheers,
--renato

On Sat, Sep 6, 2014 at 3:40 PM, Renato Golin <renato.golin at linaro.org>
wrote:
> On 6 September 2014 22:46, Saleem Abdulrasool <compnerd at
compnerd.org>
> wrote:
> > I did dig into this further and it seems that they are, in fact,
> considered
> > part of the RT-ABI :-(.  Ive committed a simple conforming
> implementation in
> > SVN r217322.
>
> Hi Saleem,
>
> This implementation will differ from the current sdiv's expected
> (return 0) if called from a place that doesn't mov r0, #0 just before
> calling div0.
>
Why not adjust this instead?

> ARM and GCC both throw an exception, and on non-EABI ARM, we're
> returning zero, so it would be good to have at least one consistent
> behaviour.
>
I think its better to avoid pulling in a dependency on the target libc,
particularly if you want to permit the use of compiler-rt in a bare-metal
environment.  This implementation conforms to the specification and can be
overridden if the libc wishes to catch the div-by-zero.

We could use __rt_raise(2, 2), which would need to call signal as well, so
you end up growing a dependency on the target environment's libc
implementation.  I think that expanding the responsibility of compiler-rt
from supporting the code generation from the compiler to integrating into
the target environment's libc can be problematic.

> I think we should return zero on both idiv0 and ldiv0 and move the
> "mov r0, #0" inside the #else for now.
>
Why 0 and not infinity?  Or some other value?

> cheers,
> --renato

-- 
Saleem Abdulrasool
compnerd (at) compnerd (dot) org
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20140907/b1effd40/attachment.html>