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

[Saleem Abdulrasool]

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>