On Fri, 11 Dec 2020, Andrew Haley via Gcc wrote:
> On 11/12/2020 07:12, Marc Glisse wrote:
> > On Thu, 10 Dec 2020, Lucas de Almeida via Gcc wrote:
> >
> >> when performing (int64_t) foo / (int32_t) bar in gcc under x86, a call to
> >> __divdi3 is always output, even though it seems the use of
On 11/12/2020 07:12, Marc Glisse wrote:
> On Thu, 10 Dec 2020, Lucas de Almeida via Gcc wrote:
>
>> when performing (int64_t) foo / (int32_t) bar in gcc under x86, a call to
>> __divdi3 is always output, even though it seems the use of the idiv
>> instruction could be faster.
>
> IIRC, idiv requi
On Thu, 10 Dec 2020, Lucas de Almeida via Gcc wrote:
when performing (int64_t) foo / (int32_t) bar in gcc under x86, a call to
__divdi3 is always output, even though it seems the use of the idiv
instruction could be faster.
IIRC, idiv requires that the quotient fit in 32 bits, while your C cod
On Thu, 10 Dec 2020, Lucas de Almeida via Gcc wrote:
> Hello,
> when performing (int64_t) foo / (int32_t) bar in gcc under x86, a call to
> __divdi3 is always output, even though it seems the use of the idiv
> instruction could be faster.
> This seems to remain even under -Ofast and other availa
Hello,
when performing (int64_t) foo / (int32_t) bar in gcc under x86, a call to
__divdi3 is always output, even though it seems the use of the idiv
instruction could be faster.
This seems to remain even under -Ofast and other available options.
To illustrate, this godbolt link: https://godbolt.or
