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

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

On Sat, Sep 06, 2014 at 03:09:27PM +0300, Sergey Dmitrouk
wrote:
> 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.
One issue is that they depend on OS-specific functionality.
E.g. the ability to raise a signal. That's primarily why I didn't add an
implementation.

Joerg

On 6 September 2014 19:39, Joerg Sonnenberger <joerg at britannica.bec.de>
wrote:
> One issue is that they depend on OS-specific functionality.
> E.g. the ability to raise a signal. That's primarily why I didn't
add an
> implementation.
According to the EABI, you can either return the argument, a specified
integer or raise a signal, so its behaviour could be OS-specific.

The current behaviour is to return 0, which is fine for most purposes,
and would work on *any* OS. We could expand the idiv0 later, based on
OS, but for now we should have the symbols defined.

cheers,
--renato

On Sat, Sep 6, 2014 at 11:39 AM, Joerg Sonnenberger <joerg at
britannica.bec.de
> wrote:
> On Sat, Sep 06, 2014 at 03:09:27PM +0300, Sergey Dmitrouk wrote:
> > 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.
>
> One issue is that they depend on OS-specific functionality.
> E.g. the ability to raise a signal. That's primarily why I didn't
add an
> implementation.

Yes, that would be the best possible solution.  However, given that the
specification calls for the definition to be weak, the c library could
override the function and provide an alternate implementation.  Conforming
to the first option doesn't require any runtime library support, so, Ive
taken the liberty of implementing that as a means to get compiler-rt usable
in an environment which does not provide a custom division-by-zero handler
from the math library.

>
> Joerg
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
-- 
Saleem Abdulrasool
compnerd (at) compnerd (dot) org
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20140906/63917da9/attachment.html>