>> "Jose E. Marchesi" writes:
>>> There are many places in GCC where alternative local sequences are
>>> tried in order to determine what is the cheapest or best alternative
>>> to use in the current target. When any of these sequences involve a
>>> libcall, the current implementation of emit_l
> "Jose E. Marchesi" writes:
>> There are many places in GCC where alternative local sequences are
>> tried in order to determine what is the cheapest or best alternative
>> to use in the current target. When any of these sequences involve a
>> libcall, the current implementation of emit_librar
"Jose E. Marchesi" writes:
> There are many places in GCC where alternative local sequences are
> tried in order to determine what is the cheapest or best alternative
> to use in the current target. When any of these sequences involve a
> libcall, the current implementation of emit_library_call_v
On Fri, Aug 18, 2023 at 06:31:10PM +0200, Jose E. Marchesi wrote:
> > This won't work if target can't use a direct call instruction.
> > Consider
> > __int128 a, b; void foo () { a = a / b; }
> > on x86_64-linux. With just -O2, the above works fine, with
> > -O2 -mcmodel=large it will not, the cal
Hi Jakub.
Thanks for the review.
> On Fri, Aug 18, 2023 at 03:53:51PM +0200, Jose E. Marchesi via Gcc-patches
> wrote:
>> --- a/gcc/final.cc
>> +++ b/gcc/final.cc
>> @@ -815,6 +815,8 @@ make_pass_compute_alignments (gcc::context *ctxt)
>> reorg.cc, since the branch splitting exposes new ins
On Fri, Aug 18, 2023 at 03:53:51PM +0200, Jose E. Marchesi via Gcc-patches
wrote:
> --- a/gcc/final.cc
> +++ b/gcc/final.cc
> @@ -815,6 +815,8 @@ make_pass_compute_alignments (gcc::context *ctxt)
> reorg.cc, since the branch splitting exposes new instructions with delay
> slots. */
>
>
