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

> Looks as though whomever implemented the call to __aeabi_idiv0 wanted
> to be conservative for non EABI targets.
How could it prevent him from providing default implementation of
__aeabi_idiv0() for EABI targets?
> AFAIK, gnueabi targets recognize all EABI functions, so that should
> work well.
Not sure I understand you, nothing in compiler-rt defines these
functions, they are left unresolved on gnueabit target for me.
> But I don't know about BSD, Darwin and other targets, how
> they would behave if we assumed those functions were always there.
We do assume they are always there for all EABI targets at the moment.
I'm wondering why it is so.  Is it left to be implemented in standard
library or something similar?

Thanks,
Sergey

On 6 September 2014 09:43, Sergey Dmitrouk <sdmitrouk at accesssoftek.com>
wrote:
> How could it prevent him from providing default implementation of
> __aeabi_idiv0() for EABI targets?
It couldn't. I was referring to this specific ifdef. That file
implements both __aeabi_uidiv and __udivsi3, and from reading that
portion, it looked to me as if that's trying to avoid requiring the
__aeabi_idiv0 symbol on non-EABI targets.

> We do assume they are always there for all EABI targets at the moment.
That's correct, and on EABI targets the symbols *should* exist. I'm in
favour for adding them ASAP, but we might need an ifdef to avoid
creating unnecessary (or conflicting) symbols for non-EABI targets.

However, according to RTABI 4.3.2:

The *div0 functions:
 Return the value passed to them as a parameter.
 Or, return a fixed value defined by the execution environment (such as 0).
 Or, raise a signal (often SIGFPE) or throw an exception, and do not return.

The current behaviour is to return zero, but it is setting the zero is
before the call to div0, which is wrong. Jon's implementation would
work in this call, but not anywhere else.

A proper solution would be to have:

LOCAL_LABEL(divby0):
#ifdef __ARM_EABI__
  b __aeabi_idiv0
#else
  mov r0, #0
  JMP(lr)
#endif

And make both __aeabi_{i,l}div0 return 0.

I'm hoping both parts of the ifdef to generate *identical* code, but
with the benefit that we can change the behaviour of div0 by
overriding the function's implementation.

cheers,
--renato

On Sat, Sep 06, 2014 at 04:48:20AM -0700, Renato Golin
wrote:
> I'm in favour for adding them ASAP, but we might need an ifdef to avoid
> creating unnecessary (or conflicting) symbols for non-EABI targets.
Sure, it makes sense.
> A proper solution would be to have:
>
> LOCAL_LABEL(divby0):
> #ifdef __ARM_EABI__
>   b __aeabi_idiv0
> #else
>   mov r0, #0
>   JMP(lr)
> #endif
>
> And make both __aeabi_{i,l}div0 return 0.
>
> I'm hoping both parts of the ifdef to generate *identical* code, but
> with the benefit that we can change the behaviour of div0 by
> overriding the function's implementation.
I missed that

    mov r0, #0

line.  It really shouldn't be there for EABI targets.

Will see what Saleem (and maybe others) thinks of this, maybe there is a
non-obvious reason to do not implement these functions in compiler-rt.

Regards,
Sergey