Pushed to both gcc11 and gcc12.
thanks.
Qing
> On May 24, 2022, at 1:19 AM, Richard Biener wrote:
>
> On Mon, 23 May 2022, Qing Zhao wrote:
>
>> Hi,
>>
>> I have added the patch to GCC11 and GCC12 in my local area and bootstrapped
>> and regress tested on both x86 and aarch64, no any
On Mon, 23 May 2022, Qing Zhao wrote:
> Hi,
>
> I have added the patch to GCC11 and GCC12 in my local area and bootstrapped
> and regress tested on both x86 and aarch64, no any issues.
>
> Can I committed them to both GCC11 and GCC12 branches?
Yes.
Thanks,
Richard.
> Thanks.
>
>
>
>
> >
Hi,
I have added the patch to GCC11 and GCC12 in my local area and bootstrapped and
regress tested on both x86 and aarch64, no any issues.
Can I committed them to both GCC11 and GCC12 branches?
Thanks.
> On May 10, 2022, at 8:38 AM, Qing Zhao via Gcc-patches
> wrote:
>
>
>
>> On May 10,
> On May 10, 2022, at 1:12 AM, Richard Biener wrote:
>
> On Mon, 9 May 2022, Uros Bizjak wrote:
>
>> On Mon, May 9, 2022 at 5:44 PM Qing Zhao wrote:
>>>
>>> Another question:
>>>
>>> I think that this patch might need to be back ported to Gcc12 and GCC11.
>>>
>>> What?s your opinion on
On Mon, 9 May 2022, Uros Bizjak wrote:
> On Mon, May 9, 2022 at 5:44 PM Qing Zhao wrote:
> >
> > Another question:
> >
> > I think that this patch might need to be back ported to Gcc12 and GCC11.
> >
> > What?s your opinion on this?
>
> It is not a regression, so following general rules, the
On Mon, May 9, 2022 at 5:44 PM Qing Zhao wrote:
>
> Another question:
>
> I think that this patch might need to be back ported to Gcc12 and GCC11.
>
> What’s your opinion on this?
It is not a regression, so following general rules, the patch should
not be backported. OTOH, the patch creates
Another question:
I think that this patch might need to be back ported to Gcc12 and GCC11.
What’s your opinion on this?
If so, when can I backport it?
thanks.
Qing
> On May 7, 2022, at 4:06 AM, Uros Bizjak wrote:
>
> On Fri, May 6, 2022 at 6:42 PM Qing Zhao wrote:
>>
>>
>>
>>> On May
> On May 7, 2022, at 4:06 AM, Uros Bizjak wrote:
>
> On Fri, May 6, 2022 at 6:42 PM Qing Zhao wrote:
>>
>>
>>
>>> On May 6, 2022, at 10:58 AM, Uros Bizjak wrote:
>>>
>>> On Fri, May 6, 2022 at 4:29 PM Qing Zhao wrote:
Hi,
As Kee’s requested in this PR:
On Fri, May 6, 2022 at 6:42 PM Qing Zhao wrote:
>
>
>
> > On May 6, 2022, at 10:58 AM, Uros Bizjak wrote:
> >
> > On Fri, May 6, 2022 at 4:29 PM Qing Zhao wrote:
> >>
> >> Hi,
> >>
> >> As Kee’s requested in this PR:
> >> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101891
> >>
> >> =
> >>
> On May 6, 2022, at 10:58 AM, Uros Bizjak wrote:
>
> On Fri, May 6, 2022 at 4:29 PM Qing Zhao wrote:
>>
>> Hi,
>>
>> As Kee’s requested in this PR:
>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101891
>>
>> =
>>
>> Currently -fzero-call-used-regs will use a pattern of:
>>
>> XOR
On Fri, May 6, 2022 at 4:29 PM Qing Zhao wrote:
>
> Hi,
>
> As Kee’s requested in this PR:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101891
>
> =
>
> Currently -fzero-call-used-regs will use a pattern of:
>
> XOR regA,regA
> MOV regA,regB
> MOV regA,regC
> ...
> RET
>
> However, this
Hi,
As Kee’s requested in this PR:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101891
=
Currently -fzero-call-used-regs will use a pattern of:
XOR regA,regA
MOV regA,regB
MOV regA,regC
...
RET
However, this introduces both a register ordering dependency (e.g. the CPU
cannot clear regB
12 matches
Mail list logo
