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

On Tue, Sep 9, 2014 at 1:37 AM, Renato Golin <renato.golin at linaro.org>
wrote:
> On 9 September 2014 02:18, Saleem Abdulrasool <compnerd at
compnerd.org>
> wrote:
> > The current implementations actually return 0.  Can you point out
where
> that
> > doesn't hold please?
>
> With the current implementation...
>
> int foo(int a) {
>   return __aeabi_idiv0(a);
> }
>
> returns 'a', while:
>
> int bar(int a) {
>   return __aeabi_idiv(a, 0);
> }
>
> returns zero.
>
>
> > Quoting the RTABI:
> >
> >    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?
>
> As I said before, all three behaviours are allowed by the RTABI
> (exception, constant, parameter), but we now have two different
> behaviours in compiler-rt. This is a regression.
>
> We must make it consistent to what there was there before (return
> zero). If you *really* want to make it return the parameter or signal,
> we should discuss this properly, on another thread, but right now,
> division by zero in compiler-rt has to return zero.

Oh!  I think I see what the confusion is all about.  __aeabi_[il]div0 are
*NOT* division routines.  They are handlers for the error case of division
by zero.  They do not perform a division by zero, they effectively are
meant to trap the fact that a division by zero has occurred.

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

On 10 September 2014 06:39, Saleem Abdulrasool <compnerd at compnerd.org>
wrote:
> Oh!  I think I see what the confusion is all about.  __aeabi_[il]div0 are
> *NOT* division routines.
Hi Saleem,

No, that's not the confusion. The {i,l}div0 functions are public and
can be called from anywhere in user code. Let me give you a better
example:

struct div_res {int quo, int rem };

struct div_res my_divmod(int a, int b) {
  struct div_res result;
  result.quo = a/b;
  result.rem = a%b;
  return div;
}

If 'b' is zero, my_divmod, when linking with compiler-rt, will return
zero. Now, a "cautious" developer has a great idea! Let me make this
function safer!

struct div_res {int quo, int rem };

struct div_res my_divmod(int a, int b) {
 if (b == 0)
    return __aeabi_idiv0(a);

  struct div_res result;
  result.quo = a/b;
  result.rem = a%b;
  return div;
}

my_divmod will now, return 'a'.

That's not acceptable.

cheers,
--renato

After a chat with Saleem, I agree that the usage in this case is ok,
since the div0 is *meant* to be implemented if any consistent
behaviour is expected, otherwise, here be dragons. Also, in its lowest
form, div0 should be just a return, which in the case of ARM, leaves
R0 intact, so returning the argument makes a lot of sense.

Ignore my musings, all is well.

cheers,
--renato

On 10 September 2014 10:40, Renato Golin <renato.golin at linaro.org>
wrote:
> On 10 September 2014 06:39, Saleem Abdulrasool <compnerd at
compnerd.org> wrote:
>> Oh!  I think I see what the confusion is all about.  __aeabi_[il]div0
are
>> *NOT* division routines.
>
> Hi Saleem,
>
> No, that's not the confusion. The {i,l}div0 functions are public and
> can be called from anywhere in user code. Let me give you a better
> example:
>
> struct div_res {int quo, int rem };
>
> struct div_res my_divmod(int a, int b) {
>   struct div_res result;
>   result.quo = a/b;
>   result.rem = a%b;
>   return div;
> }
>
> If 'b' is zero, my_divmod, when linking with compiler-rt, will
return
> zero. Now, a "cautious" developer has a great idea! Let me make
this
> function safer!
>
> struct div_res {int quo, int rem };
>
> struct div_res my_divmod(int a, int b) {
>  if (b == 0)
>     return __aeabi_idiv0(a);
>
>   struct div_res result;
>   result.quo = a/b;
>   result.rem = a%b;
>   return div;
> }
>
> my_divmod will now, return 'a'.
>
> That's not acceptable.
>
> cheers,
> --renato