[LLVMdev] [Compiler-RT] [ARM] Where __aeabi_[il]div0 builtins should be implemented?
Renato Golin
renato.golin at linaro.org
Sat Sep 6 04:48:20 PDT 2014
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
More information about the llvm-dev
mailing list