More OLD PROBLEMS problems

[Ian Lance Taylor]

Steven Bosscher <stevenb@suse.de> writes:

> Here we go:
> 
>   <li value="38">Hack <code>expand_mult</code> so that if there is no
>   same-modes multiply it will use a widening multiply and then truncate
>   rather than calling the library.</li>
> 
> I couldn't find where expand_mult does do this, but it appears that
> this problem was fixed at one point.  For example:

I think this was fixed here:

Fri Aug 21 07:53:12 1992  Richard Kenner  (kenner@vlsi1.ultra.nyu.edu)

	* optabs.c (expand_binop): If, e.g., mulqi3 doesn't exist, try
	mulqihi3.

The entry in PROBLEMS has been there at least since February 1992,
when the file was first entered into RCS.

I think this problem should be removed.

>   <li value="39">Hack expanding of division to notice cases for long ->
>   short division.</li>
> 
> Ehm right, I don't understand this problem.  Anyone?

I assume it means the inverse of the previous problems: look for cases
where we can do a division yielding an shorter result.  For example,
the m68k divs.w instruction will divide SImode by HImode, yielding
HImode.  For that matter, m68k divs.l will divide DImode by SImode,
yielding SImode.  I don't know of any modern processors with these
types of shortening divide instructions, so I think this problem
should also be removed if it even still exists.

>   <li value="40">Represent divide insns as (DIV:SI ...) followed by a
>   separate lowpart extract.  Represent remainder insns as DIV:SI
>   followed by a separate highpart extract.  Then cse can work on the
>   DI V:SI part.  Problem is, this may not be desirable on machines where
>   computing the quotient alone does not necessarily give a
>   remainder--such as the 68020 for long operands.</li>
> 
> I don't think we want to do this.

No, this is pretty m68k specific.

>   <li value="69">Define the floating point converting arithmetic
>   instructions for the 68881.</li>
> 
> Which instructions are this?  Are they implemented?  (Schwab? ;-)

I assume they mean fsgldiv and fsglmul.  They appear to be supported,
so this problem should be removed.

>   <li value="96">Can do SImode bitfield insns without reloading, but must
>   alter the operands in special ways.</li>
> 
> Another one that could use some explaining.

I would guess that this refers to m68k instructions like bfset which
can take a memory operand.  In memory they refer to a single byte, and
as such using them on SImode would require adjusting to the right byte
and changing the bit number.  This does not appear to be implemented
although it's not clear that anybody cares.

>   <li value="112">Can convert float to unsigned int by subtracting a
>   constant, converting to signed int, and changing the sign bit.</li>
> 
> And again.

I think this means that you can convert double to unsigned int by
subtracting 0x80000000, converting to int, and flipping the sign bit.
This might be useful if the processor has an instruction which
converts floating point to int, but doesn't have one which converts to
unsigned int.  Say, the m68k fintrz instruction.  This is done in
expand_fix() in optabs.c, so this problem is fixed.

>   <li value="122">When <code>insn-output.c</code> turns a bit-test into a
>   sign-test, it should see whether the condition code is already set up
>   with that sign.</li>
> 
> Isn't this a job for final?

I don't think it's a job for any one place these days.  At least, I
don't know of any code which converts bit tests into sign tests and
which would simultaneously worry about whether the condition has
already been set up.  I would vote for removing this problem also.

Ian