Jeff Law writes:
> On 04/02/14 06:08, Anthony Green wrote:
>>
>> One embarrassing feature of the moxie compiler port is that it really
>> doesn't understand how to promote integral types. Moxie cores
>> zero-extend all loads, but the compiler still shifts loaded values back
>> and forth to zero
Joern Rennecke writes:
> On 2 April 2014 13:08, Anthony Green wrote:
>
>> I though the answer was to simply add something like this...
>>
>> (define_insn "zero_extendqisi"
>> [(set (match_operand:SI 0 "register_operand" "=r")
>> (zero_extend:SI (match_operand:QI 1 "register_operand" "r
On 04/02/14 06:08, Anthony Green wrote:
One embarrassing feature of the moxie compiler port is that it really
doesn't understand how to promote integral types. Moxie cores
zero-extend all loads, but the compiler still shifts loaded values back
and forth to zero out the upper bits.
I'm a bit sur
On 2 April 2014 13:08, Anthony Green wrote:
> I though the answer was to simply add something like this...
>
> (define_insn "zero_extendqisi"
> [(set (match_operand:SI 0 "register_operand" "=r")
> (zero_extend:SI (match_operand:QI 1 "register_operand" "r")))]
> ""
> "; ZERO EXTEND (
One embarrassing feature of the moxie compiler port is that it really
doesn't understand how to promote integral types. Moxie cores
zero-extend all loads, but the compiler still shifts loaded values back
and forth to zero out the upper bits.
So...
unsigned int foo (unsigned char *c)
{
return
