On Thu, 29 Oct 2020, Richard Sandiford via Gcc-patches wrote:
> Hongtao Liu via Gcc-patches <gcc-patches@gcc.gnu.org> writes:
> > On Tue, Oct 27, 2020 at 7:13 PM Richard Sandiford
> > <richard.sandif...@arm.com> wrote:
> >>
> >> Hongtao Liu via Gcc-patches <gcc-patches@gcc.gnu.org> writes:
> >> > Hi:
> >> > For inline asm, there could be an operand like (not (mem:)), it's
> >> > not a valid operand for normal memory constraint.
> >> > Bootstrap is ok, regression test is ok for make check
> >> > RUNTESTFLAGS="--target_board='unix{-m32,}'"
> >> >
> >> > gcc/ChangeLog
> >> > PR target/97540
> >> > * ira.c: (ira_setup_alts): Extract memory from operand only
> >> > for special memory constraint.
> >> > * recog.c (asm_operand_ok): Ditto.
> >> > * lra-constraints.c (process_alt_operands): MEM_P is
> >> > required for normal memory constraint.
> >> >
> >> > gcc/testsuite/ChangeLog
> >> > * gcc.target/i386/pr97540.c: New test.
> >>
> >> Sorry to stick my oar in, but I think we should reconsider the
> >> bcst_mem_operand approach. It seems like these patches (and the
> >> previous one) are fighting against the principle that operands
> >> cannot be arbitrary expressions.
> >>
> >> This kind of thing was attempted long ago (even before my time!)
> >> for SIGN_EXTEND on MIPS. It ended up causing more problems than
> >> it solved and in the end it had to be taken out. I'm worried that
> >> we might end up going through the same cycle again.
> >>
> >
> > Could you provide the thread link for the issue of SIGN_EXTEND on
> > MIPS, then I can take a look to see if it's exactly the same issue as
> > mine.
>
> I couldn't find anything, sorry. The patch that finally removed
> the MIPS handling was:
>
> https://gcc.gnu.org/pipermail/gcc-patches/2002-October/088178.html
>
> I know there was some discussion about the problems around then,
> but some of it might have been private rather than on-list.
> I can't remember the details now.
To further muddy the waters, I vaguely remember the SH makes (or
made) use of some peculiar feature regarding (optional?)
sign/zero-extend in operands. Joern and I had an "exchange of
views" where I (IIRC) wanted to remove a supporting middle-end
feature which was in the way of something I wanted to do and
actually didn't help the SH. (Register allocation silently
swallowing an unary operator in constraints?) I think he
conceded but the legwork to remove it was never done.
Point being, to make that bell ring, perhaps it helps to look in
mail archives even long before then (maybe before 2000) or at
least a look at the SH port. Looking there now, maybe it's
related to its arith_reg_operand, that oddly appears to allow
sign_extend but where the body doesn't match it due to an #if 0.
So, all support has likely decayed since then and now be just
dust...
brgds, H-P
