Alexander,
(Sorry for the late reply due to holiday vacation).
> On Dec 24, 2022, at 3:10 AM, Alexander Monakov wrote:
>
>
> On Fri, 23 Dec 2022, Qing Zhao wrote:
>
>> BTW, Why sched1 is not enabled on x86 by default?
>
> Register allocation is tricky on x86 due to small number of
Hi!
On Sat, Dec 24, 2022 at 10:58:41AM +0100, Jose E. Marchesi via Gcc-patches
wrote:
> Allright, so we have two short-term alternatives for at least remove the
> possibility that GCC generates wrong code for valid C when the scheduler
> is turned on:
>
> a) To disable sched1 in functions that
On Sat, 24 Dec 2022, Jose E. Marchesi wrote:
> However, there is something I don't understand: wouldn't sched2
> introduce the same problem when -fsched2-use-superblocks is specified?
Superblocks are irrelevant, a call instruction does not end a basic block
and the problematic motion happens
> Am 24.12.2022 um 10:54 schrieb Jose E. Marchesi :
>
>
Am 24.12.2022 um 09:11 schrieb Alexander Monakov via Gcc-patches
:
>>>
>>>
On Fri, 23 Dec 2022, Qing Zhao wrote:
BTW, Why sched1 is not enabled on x86 by default?
>>>
>>> Register allocation is tricky on
>> Am 24.12.2022 um 09:11 schrieb Alexander Monakov via Gcc-patches
>> :
>>
>>
>>> On Fri, 23 Dec 2022, Qing Zhao wrote:
>>>
>>> BTW, Why sched1 is not enabled on x86 by default?
>>
>> Register allocation is tricky on x86 due to small number of general-purpose
>> registers, and sched1 can
> Am 24.12.2022 um 09:11 schrieb Alexander Monakov via Gcc-patches
> :
>
>
>> On Fri, 23 Dec 2022, Qing Zhao wrote:
>>
>> BTW, Why sched1 is not enabled on x86 by default?
>
> Register allocation is tricky on x86 due to small number of general-purpose
> registers, and sched1 can make it
On Fri, 23 Dec 2022, Qing Zhao wrote:
> BTW, Why sched1 is not enabled on x86 by default?
Register allocation is tricky on x86 due to small number of general-purpose
registers, and sched1 can make it even more difficult. I think before register
pressure modeling was added, sched1 could not be
> On Dec 23, 2022, at 2:36 PM, Alexander Monakov wrote:
>
>
>
> On Fri, 23 Dec 2022, Qing Zhao wrote:
>
>> Then, sched2 still can move insn across calls?
>> So does sched2 have the same issue of incorrectly moving the insn across a
>> call which has unknown control flow?
>
> I think
On Fri, 23 Dec 2022, Qing Zhao wrote:
> Then, sched2 still can move insn across calls?
> So does sched2 have the same issue of incorrectly moving the insn across a
> call which has unknown control flow?
I think problems are unlikely because register allocator assigns pseudos that
cross
Then, sched2 still can move insn across calls?
So does sched2 have the same issue of incorrectly moving the insn across a
call which has unknown control flow?
Qing
> On Dec 23, 2022, at 12:31 PM, Alexander Monakov wrote:
>
>
> On Fri, 23 Dec 2022, Jose E. Marchesi wrote:
>
>>> (scheduling
> On Fri, 23 Dec 2022, Jose E. Marchesi wrote:
>
>> > (scheduling across calls in sched2 is somewhat dubious as well, but
>> > it doesn't risk register pressure issues, and on VLIW CPUs it at least
>> > can result in better VLIW packing)
>>
>> Does sched2 actually schedule across calls? All
On Fri, 23 Dec 2022, Jose E. Marchesi wrote:
> > (scheduling across calls in sched2 is somewhat dubious as well, but
> > it doesn't risk register pressure issues, and on VLIW CPUs it at least
> > can result in better VLIW packing)
>
> Does sched2 actually schedule across calls? All the
> On Fri, 23 Dec 2022, Qing Zhao wrote:
>> >> I am a little confused, you mean pre-RA scheduler does not look at the
>> >> data flow
>> >> information at all when scheduling insns across calls currently?
>> >
>> > I think it does not inspect liveness info, and may extend lifetime of a
>> >
On Fri, 23 Dec 2022, Qing Zhao wrote:
> >> I am a little confused, you mean pre-RA scheduler does not look at the
> >> data flow
> >> information at all when scheduling insns across calls currently?
> >
> > I think it does not inspect liveness info, and may extend lifetime of a
> > pseudo
> >
> On Dec 23, 2022, at 2:33 AM, Alexander Monakov wrote:
>
>
> On Thu, 22 Dec 2022, Qing Zhao wrote:
>
>>> I think scheduling across calls in the pre-RA scheduler is simply an
>>> oversight,
>>> we do not look at dataflow information and with 50% chance risk extending
>>> lifetime of a
> Alexander Monakov via Gcc-patches writes:
>> On Thu, 22 Dec 2022, Jose E. Marchesi via Gcc-patches wrote:
>>
>>> The first instruction scheduler pass reorders instructions in the TRY
>>> block in a way `b=true' gets executed before the call to the function
>>> `f'. This optimization is
Alexander Monakov via Gcc-patches writes:
> On Thu, 22 Dec 2022, Jose E. Marchesi via Gcc-patches wrote:
>
>> The first instruction scheduler pass reorders instructions in the TRY
>> block in a way `b=true' gets executed before the call to the function
>> `f'. This optimization is wrong, because
On Thu, 22 Dec 2022, Qing Zhao wrote:
> > I think scheduling across calls in the pre-RA scheduler is simply an
> > oversight,
> > we do not look at dataflow information and with 50% chance risk extending
> > lifetime of a pseudoregister across a call, causing higher register
> > pressure at
>
> On Dec 22, 2022, at 12:56 PM, Alexander Monakov wrote:
>
>
> On Thu, 22 Dec 2022, Jose E. Marchesi via Gcc-patches wrote:
>
>> The first instruction scheduler pass reorders instructions in the TRY
>> block in a way `b=true' gets executed before the call to the function
>> `f'. This
On Thu, 22 Dec 2022, Jose E. Marchesi via Gcc-patches wrote:
> The first instruction scheduler pass reorders instructions in the TRY
> block in a way `b=true' gets executed before the call to the function
> `f'. This optimization is wrong, because `main' calls setjmp and `f'
> is known to call
When the following testcase is built with -fschedule-insns in either
x86_64 or aarch64:
#include
#include
#include
jmp_buf ex_buf__;
#define TRY do{ if( !setjmp(ex_buf__) ){
#define CATCH } else {
#define ETRY } }while(0)
#define THROW longjmp(ex_buf__, 1)
int f(int x)
21 matches
Mail list logo
