DJ Delorie writes:
>> Sorry for missing the truncation patterns, I should have grepped
>> more than m32c.md. They look a lot like normal moves though. Is
>> truncation really not a noop, or are the patterns there to work
>> around something (probably this :-))?
>
> Not sure which pattern you're
> Sorry for missing the truncation patterns, I should have grepped
> more than m32c.md. They look a lot like normal moves though. Is
> truncation really not a noop, or are the patterns there to work
> around something (probably this :-))?
Not sure which pattern you're talking about, but in gene
Richard Sandiford writes:
> Bernd Schmidt writes:
>> On 04/27/2013 10:39 AM, Richard Sandiford wrote:
>>> Argh, that's unfortunate. The point of that change was to make
>>> simplify_gen_unary (TRUNCATE, ...) no worse than using a subreg.
>>> Would the equivalent lowpart simplify_gen_subreg call
Bernd Schmidt writes:
> On 04/27/2013 10:39 AM, Richard Sandiford wrote:
>> Argh, that's unfortunate. The point of that change was to make
>> simplify_gen_unary (TRUNCATE, ...) no worse than using a subreg.
>> Would the equivalent lowpart simplify_gen_subreg call succeed
>> (return nonnull)? If
On 04/27/2013 10:39 AM, Richard Sandiford wrote:
> Argh, that's unfortunate. The point of that change was to make
> simplify_gen_unary (TRUNCATE, ...) no worse than using a subreg.
> Would the equivalent lowpart simplify_gen_subreg call succeed
> (return nonnull)? If so, I think we want truncate
Bernd Schmidt writes:
> This patch here:
> http://gcc.gnu.org/ml/gcc-patches/2012-10/msg00661.html
>
> changed simplification code from
> case TRUNCATE:
> - /* We can't handle truncation to a partial integer mode here
> - because we don't know the real bitsize of the partial
>
