Re: [G]CSE of extended asm statements

[Bernd Schmidt <bernds at cygnus dot co dot uk>]

On Wed, 30 Aug 2000, Richard Henderson wrote:

> Or were you asking why we put a parallel in the call?  Well, that's a bit
> tougher to answer.  Without doing archaeology (or asking Jim), I know that
> FUNCTION_ARG and FUNCTION_VALUE return a parallel when they want to say
> that an argument goes multiple places.
> 
> With arguments, we use emit_group_load which turns this into a series of
> normal moves.  With the return value, we plop this struct in to the
> SET_DEST of the call, then use emit_group_store to put it somewhere that
> the compiler can deal with it.
> 
> Now, it's possible that the only reason we're currently getting away with
> this is that all the registers in this parallel are hard regs, and they're
> all call-clobbered, and they're attached to a call.  I know that sched 
> has code to handle this case, but I can't think who else does.
> 
> However, I do kinda like it as an alternative to rtl replication, which
> has also caused us problems.  I can think of at least one case where
> asm_operands is special-cased to ignore all but the first replication.

My problem with this is that it's yet another thing you have to think about
when working on code that tries to gather information from rtl or tries to
transform rtl.  It would be so much easier to work with our internal
representation if it was somehow more regular and had fewer of these
"features".

Think of the bugs we are having for example with match_dups in SSA.  This
is IMO the same problem - rtl allows something that is kind of useful for
a port or two, but could be achieved in other ways as well (e.g. matching
constraints), and it immediately becomes much harder to just take an
algorithm from a compiler book and implement it in gcc.  (ADDRESSOF falls
into the same category of things that bend rtl, often beyond the point
where it breaks.)

It may not be so bad for calls due to the reasons you gave - if it only
ever happens for hard regs in call patterns, I can see why most of the
compiler wouldn't care.  I'm terrified by the thought of extending it to
asms, though.
What would prevent us from allowing call patterns to look e.g. like

(parallel
 [(call foo)
  (set (reg:SI returnreg1) (call_result:SI 1)
  (set (reg:SF returnreg2) (call_result:SF 2)
  ....
 ])

I wouldn't call it very pretty either, but it's less likely to give
optimization passes a hard time - all the sets are easily recognizable
in a format that is used by all the other insns.  It's basically an
UNSPEC in disguise, and we already have UNSPECs.


Bernd