Re: [PATCH, x86_64]: Provide longlong.h definitions for 128bit operations

[Ian Lance Taylor <iant at google dot com>]

Roman Zippel <zippel@linux-m68k.org> writes:

> To handle this one could either rerun combine after split (which may 
> be done more than once) or we need a combined combine/split pass (which 
> selectively just combines the newly created instructions with other 
> instructions).

I agree that we don't handle all cases at present.


> > > I think the reload problem may not be that bad, while a move instruction 
> > > sets the cc register, it often just sets it in the same way as the 
> > > previous instructions, especially the Z and M flag, which is enough for 
> > > the common test against zero. For these tests the move wouldn't really 
> > > clobber the flags, but just recreate them.
> > 
> > It's unfortunately not that simple.  In some cases reload will need to
> > load some part of an address.  When it does that the flags will no
> > longer have any relation to what they are supposed to have.
> 
> This requires an output reload, doesn't it? If we only have single output, 
> it would mean the final move would recreate the right flags.
> For floating point values this would be even easier, the post processing 
> for setting the condition codes is always the same and move to memory 
> doesn't even change them.

No, reloading an address can be for either an input or an output.  It
will typically but not exclusively be expressed as
RELOAD_FOR_INPUT_ADDRESS or RELOAD_FOR_OUTPUT_ADDRESS.


> > > A bit more difficult is a sub/cmp combination, here move would really 
> > > clobber flags, but luckily on m68k the sub instruction is quite flexible 
> > > and e.g. also accepts memory arguments as destination, so it would be 
> > > possible to convert a output reload into one or two input reloads.
> > > So what basically would be needed is a port specific check in reload as to 
> > > whether an output reload is acceptable and possibly reject the 
> > > alternative and try it with another one.
> > > That's currently the idea I would favour at least for m68k, does that 
> > > sound reasonable (or at least understandable :) ).
> > 
> > That sounds unreasonable.  reload is already very complicated, too
> > complicated, and there isn't going to be any way to drop in something
> > like that without making it significantly more complicated.
> 
> Considering the alternatives I don't want dismiss this option too quickly.
> What is suggested in the wiki would only trade one problem with another, 
> cc0 might be gone this way, but one also had none of the benefits and 
> needs a lot of extra work to get anywhere near where it was before.
> The problem _is_ reload, so I'd prefer to look at the real problem instead 
> of wasting a lot of effort to work around it.
> Why are you so sure that there is not "any way"? Yes, reload is 
> complicated, but I don't think these changes would make it significantly 
> more complicated than it already is and I'm pretty sure that it will be 
> less complicated than any of the alternatives.

Certainly the problem is reload and the answer is to eliminate it.
That is extremely hard but will solve the problem for good.

If you want to look at target specific routines to guide instruction
selection in reload, that is your choice.  I do not think it would be
a wise way to approach this problem.

Ian