On 3/30/23 18:01, Hans-Peter Nilsson wrote:
On Fri, 24 Mar 2023, Peter Bergner via Gcc-patches wrote:
On 3/23/23 6:12 PM, Jeff Law via Gcc-patches wrote:
Is there a reason why REE cannot see that our (reg:QI 4) is a param register
and thus due to our ABI, already correctly sign/zero
On Fri, 24 Mar 2023, Peter Bergner via Gcc-patches wrote:
> On 3/23/23 6:12 PM, Jeff Law via Gcc-patches wrote:
> Is there a reason why REE cannot see that our (reg:QI 4) is a param
> register
> and thus due to our ABI, already correctly sign/zero extended?
> >>>
> >>> I don't
On 3/24/23 15:34, Peter Bergner wrote:
On 3/23/23 6:12 PM, Jeff Law via Gcc-patches wrote:
Is there a reason why REE cannot see that our (reg:QI 4) is a param register
and thus due to our ABI, already correctly sign/zero extended?
I don't think REE has ever considered exploiting ABI
On 3/23/23 6:12 PM, Jeff Law via Gcc-patches wrote:
Is there a reason why REE cannot see that our (reg:QI 4) is a param
register
and thus due to our ABI, already correctly sign/zero extended?
>>>
>>> I don't think REE has ever considered exploiting ABI constraints. Handling
>>>
On 3/23/23 10:53, Peter Bergner wrote:
On 3/23/23 11:32 AM, Jeff Law via Gcc-patches wrote:
On 3/23/23 10:29, Peter Bergner wrote:
I'm sorry that I don't know how REE works. Why can't it optimize this?
I see in the REE dump:
(insn 20 18 22 3 (set (reg:DI 4 4)
On 3/23/23 11:32 AM, Jeff Law via Gcc-patches wrote:
> On 3/23/23 10:29, Peter Bergner wrote:
>> I'm sorry that I don't know how REE works. Why can't it optimize this?
>> I see in the REE dump:
>>
>> (insn 20 18 22 3 (set (reg:DI 4 4)
>>(zero_extend:DI (reg:QI 4 4
On 3/23/23 10:29, Peter Bergner wrote:
https://gcc.gnu.org/PR41742
These are not addressed in the trunk patch, because int c is not initialized
with registers and for this reason we cannot eliminate them. If we initialize
int c then zero extension goes away.
I'm sorry that I don't
On 3/23/23 8:47 AM, Jeff Law wrote:
> On 3/23/23 04:38, Ajit Agarwal wrote:
>> * ree.cc: Modification for AND opcode support to eliminate
>> unnecessary signed extension.
>> * testsuite/g++.target/powerpc/sext-elim.C: New tests.
> Just a note. I'll look at this once the trunk is open
On 23/03/23 7:17 pm, Jeff Law wrote:
>
>
> On 3/23/23 04:38, Ajit Agarwal wrote:
>>
>> Hello All:
>>
>> This patch removed unnecessary signed extension elimination in ree pass.
>> Bootstrapped and regtested on powerpc64-linux-gnu.
>>
>>
>> Thanks & Regards
>> Ajit
>>
>> rtl-optimization:
Hello Peter:
On 23/03/23 6:08 pm, Peter Bergner wrote:
> On 3/23/23 5:38 AM, Ajit Agarwal wrote:
>> This patch removed unnecessary signed extension elimination in ree pass.
>> Bootstrapped and regtested on powerpc64-linux-gnu.
>>
>>
>> Thanks & Regards
>> Ajit
>>
>> rtl-optimization: ppc
Hello Peter:
On 23/03/23 6:08 pm, Peter Bergner wrote:
> On 3/23/23 5:38 AM, Ajit Agarwal wrote:
>> This patch removed unnecessary signed extension elimination in ree pass.
>> Bootstrapped and regtested on powerpc64-linux-gnu.
>>
>>
>> Thanks & Regards
>> Ajit
>>
>> rtl-optimization: ppc
On 3/23/23 04:38, Ajit Agarwal wrote:
Hello All:
This patch removed unnecessary signed extension elimination in ree pass.
Bootstrapped and regtested on powerpc64-linux-gnu.
Thanks & Regards
Ajit
rtl-optimization: ppc backend generates unnecessary signed extension.
On 3/23/23 5:38 AM, Ajit Agarwal wrote:
> This patch removed unnecessary signed extension elimination in ree pass.
> Bootstrapped and regtested on powerpc64-linux-gnu.
>
>
> Thanks & Regards
> Ajit
>
> rtl-optimization: ppc backend generates unnecessary signed extension.
>
>
Hello All:
This patch removed unnecessary signed extension elimination in ree pass.
Bootstrapped and regtested on powerpc64-linux-gnu.
Thanks & Regards
Ajit
rtl-optimization: ppc backend generates unnecessary signed extension.
Eliminate unnecessary redundant signed
14 matches
Mail list logo
