On 18/01/14 20:11, pins...@gmail.com wrote:
On Jan 18, 2014, at 12:04 PM, "Paulo J. Matos" wrote:
On 17/01/14 17:36, Eric Botcazou wrote:
I am not implying that this is a GCC bug, unless you think
WORD_REISTER_OPERATIONS should have avoided the creation of such
paradoxical subreg.
No, tha
> On Jan 18, 2014, at 12:04 PM, "Paulo J. Matos" wrote:
>
> On 17/01/14 17:36, Eric Botcazou wrote:
>>> I am not implying that this is a GCC bug, unless you think
>>> WORD_REISTER_OPERATIONS should have avoided the creation of such
>>> paradoxical subreg.
>>
>> No, that's precisely the contrar
On 17/01/14 17:36, Eric Botcazou wrote:
I am not implying that this is a GCC bug, unless you think
WORD_REGISTER_OPERATIONS should have avoided the creation of such
paradoxical subreg.
No, that's precisely the contrary, WORD_REGISTER_OPERATIONS tends to create
paradoxical subregs.
I might th
> I am not implying that this is a GCC bug, unless you think
> WORD_REGISTER_OPERATIONS should have avoided the creation of such
> paradoxical subreg.
No, that's precisely the contrary, WORD_REGISTER_OPERATIONS tends to create
paradoxical subregs.
> What I was looking after was for a generic sol
> -Original Message-
> From: Eric Botcazou [mailto:ebotca...@adacore.com]
> Sent: 17 January 2014 16:23
> To: Paulo Matos
> Cc: gcc@gcc.gnu.org
> Subject: Re: Avoiding paradoxical subregs
>
> > I can use canonicalize_comparison like s390 to remove the subreg, ho
> I can use canonicalize_comparison like s390 to remove the subreg, however
> the question then becomes about how to avoid this in general. We cannot
> allow a zero_extend to become a paradoxical subreg and then have the subreg
> discarded. Most of our instructions are vector instructions which wil
Hello,
I am seeing GCC combining:
(insn 17 16 18 3 (set (reg:SI 104 [ D.4588 ])
(zero_extend:SI (reg:HI 103 [ D.4587 ]))) test-18.c:24 1426
{zero_extendhisi2}
(expr_list:REG_DEAD (reg:HI 103 [ D.4587 ])
(nil)))
(insn 18 17 19 3 (set (reg:BI 105)
(gt:BI (reg:SI 104 [ D
