On 12/22/2010 06:54 AM, Paolo Bonzini wrote:
> On 12/22/2010 03:43 PM, Bingfeng Mei wrote:
>> Thanks for letting me know this. Since only our target experiences such
>> issue, I guess no other processors have such requirements of manipulating
>> BImode. I can live with the workaround now.
>
> Perh
On 12/22/2010 03:43 PM, Bingfeng Mei wrote:
Thanks for letting me know this. Since only our target experiences such
issue, I guess no other processors have such requirements of manipulating
BImode. I can live with the workaround now.
Perhaps Blackfin, but it has a BI->SI extension instruction s
> -Original Message-
> From: Paolo Bonzini [mailto:paolo.bonz...@gmail.com] On Behalf Of Paolo
> Bonzini
> Sent: 22 December 2010 14:33
> To: Claudiu Zissulescu
> Cc: Bingfeng Mei; gcc@gcc.gnu.org
> Subject: Re: BImode is treated as normal byte-wide mode and caus
On 12/20/2010 12:43 PM, Claudiu Zissulescu wrote:
Hi,
Why don't you use a define_insn "zero_extendbisi2" which generates
your conversion instruction.
You're right that this should be a valid workaround, but Bingfeng
reported a bug indeed.
(zero_extend:SI (reg:BI 120))
should have been tran
Hi,
Why don't you use a define_insn "zero_extendbisi2" which generates
your conversion instruction. You can also use a define_insn_and_split
if you have multiple instructions to generate. The
define_insn_and_split should take place after reload is completed.
Hence, you will avoid working on subreg
Hi,
I am investigating a bug in our target port. It is
due to following optimization done by combine pass.
(zero_extend:SI (reg:BI 120))
is transformed to
(and:SI (subreg:SI (reg:BI 120) 0)
(const_int 255 [0xff]))
in expand_compound_operation (combine.c), where BImode is
just treated as
