Adam Nemet writes:
> > > I think the right fix is to call convert_to_mode or convert_move in the
> > > expansion code which ensure the proper truncation.
> >
> > That would yield correct code, but wouldn't it throw away the fact
> > that the high bits are already known to be zero, and yield redu
Mat Hostetter writes:
> Adam Nemet writes:
>
> > Ian Lance Taylor writes:
> > > Mat Hostetter writes:
> > >
> > >> Since the high bits are already zero, that would be less efficient on
> > >> most platforms, so guarding it with something like this would probably
> > >> be smarter:
> > >>
> > >>
Adam Nemet writes:
> Ian Lance Taylor writes:
> > Mat Hostetter writes:
> >
> >> Since the high bits are already zero, that would be less efficient on
> >> most platforms, so guarding it with something like this would probably
> >> be smarter:
> >>
> >> if (targetm.mode_rep_extended (mode, GE
Ian Lance Taylor writes:
> Mat Hostetter writes:
>
>> Since the high bits are already zero, that would be less efficient on
>> most platforms, so guarding it with something like this would probably
>> be smarter:
>>
>> if (targetm.mode_rep_extended (mode, GET_MODE(x)) == SIGN_EXTEND)
>> ret
Mat Hostetter writes:
> Since the high bits are already zero, that would be less efficient on
> most platforms, so guarding it with something like this would probably
> be smarter:
>
> if (targetm.mode_rep_extended (mode, GET_MODE(x)) == SIGN_EXTEND)
> return simplify_gen_unary (TRUNCATE, m
I am porting gcc-4.4.3 to TILE-Gx, a 64-bit VLIW RISC. It's gone
pretty well so far; most tests work, Linux builds, etc. Thanks for
writing such good documentation.
This chip, like MIPS64, maintains the invariant that SImode values in
DImode registers are always sign-extended. So I have impleme
