This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Make m32c build, fix PSImode truncation


Bernd Schmidt <bernds@codesourcery.com> 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
> -         integer mode.  */
> -      if (GET_MODE_CLASS (mode) == MODE_PARTIAL_INT)
> -        break;
>
> to
> +      if (GET_MODE_CLASS (mode) == MODE_PARTIAL_INT)
> +       {
> +         if (TRULY_NOOP_TRUNCATION_MODES_P (mode, GET_MODE (op)))
> +           return rtl_hooks.gen_lowpart_no_emit (mode, op);
> +         /* We can't handle truncation to a partial integer mode here
> +            because we don't know the real bitsize of the partial
> +            integer mode.  */
> +         break;
> +       }
>
> This is problematic for m32c; it defines TRULY_NOOP_TRUNCATION as 1, and
> it's not really possible to define it meaningfully for partial int
> modes, since it only gets passed precisions. Allowing subregs of PSImode
> values leads to out of registers reload failures, so it kind of relies
> on the previous behaviour.

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 to do the same.

What simplification is this blocking, and why does it lead to
reload failures?

Thanks,
Richard


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]