Re: New pseudos in splitters

2020-09-29 Thread Hans-Peter Nilsson
On Wed, 23 Sep 2020, Ilya Leoshkevich via Gcc wrote:
> Hi,
>
> "Defining How to Split Instructions" in gccint states the following:
>
> The preparation-statements are similar to those statements that are
> specified for define_expand ... Unlike those in define_expand, however,
> these statements must not generate any new pseudo-registers.
>
> I see that there is code that does this anyway, e.g. "Split
> calculate_pic_address into pic_load_addr_* and a move." in arm.md.
>
> Is this restriction still valid today?  Is there a reason we can't
> introduce new pseudos in a splitter before LRA?

There are passes splitting insns before register allocation.
The pattern after the quoted comment 6557 gates its call to
gen_reg_rtx conditional by can_create_pseudo_p (), thus is
valid.

IIUC the restriction is still in place, but the gccint section
you quote should be updated to the effect of "must not generate
any new pseudo-registers *after register allocation has started,
@xref{How-to-conditionalize-pre-post-reload}*" with the xref
referring to a new section to-be-written from pieces given by
grep reload_completed and can_create_pseudo_p.

brgds, H-P


Re: New pseudos in splitters

2020-09-23 Thread Jim Wilson
On Wed, Sep 23, 2020 at 7:51 AM Ilya Leoshkevich via Gcc
 wrote:
> Is this restriction still valid today?  Is there a reason we can't
> introduce new pseudos in a splitter before LRA?

See
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91683
for an example of what can go wrong when a splitter creates a new
pseudo.  I think there was another one I fixed around the same time
that failed for a different reason, but don't have time to look for
it.

Jim