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

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>

> Why not adjust this instead?
I was just being conservative. I don't know what else depends on this
library and I don't want to change things outside of my scope.

Since returning zero is consistent with the EABI, I don't think we
should deviate from that norm, not without a lot of thought, at least.

> 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 wasn't proposing we signal, but that we return zero, instead of the
argument.

Today we return either zero (in divmod/div/mod) or the argument (when
calling div0 directly), and that's just wrong.

> Why 0 and not infinity?  Or some other value?
Because 0 is what it was before.

cheers,
--renato

On Mon, Sep 8, 2014 at 1:19 AM, Renato Golin <renato.golin at linaro.org>
wrote:
> > Why not adjust this instead?
>
> I was just being conservative. I don't know what else depends on this
> library and I don't want to change things outside of my scope.
>
The current implementations actually return 0.  Can you point out where
that doesn't hold please?  If you look at the generated code, in reality,
the function is to spec as `bx lr'.  The intent is that it provides a hook
where you can break (without changing any state) OR replace it with the
implementation that you prefer.

> Since returning zero is consistent with the EABI, I don't think we
> should deviate from that norm, not without a lot of thought, at least.

Yes, although the current implementation also is consistent with EABI.

> > 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 wasn't proposing we signal, but that we return zero, instead of the
> argument.
>
Fair enough.  However, the point is that emulating GCC's behavior of the
exception is what I was referring to.

> Today we return either zero (in divmod/div/mod) or the argument (when
> calling div0 directly), and that's just wrong.

Quoting the RTABI:

   1.

      int __aeabi_idiv0(int return_value);
      long long __aeabi_ldiv0(long long return_value);

   The *div0 functions:

   􏰁  Return the value passed to them as a parameter.


 Is my copy out of date?

> > Why 0 and not infinity?  Or some other value?
>
> Because 0 is what it was before.
>
> 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/20140908/c55283f0/attachment.html>