Re: More OLD PROBLEMS problems

[Peter Barada <peter at the-baradas dot com>]

>>   <li value="39">Hack expanding of division to notice cases for long -&gt;
>>   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.

On the 68000, the only divide instructions were the
divs.w/divu.w, and the result is the quotient and remainder, both in
16 bits.  This meant that extra code had to be added to check for
overflow and calculate the result in software:

 divs.w %d0,%d1  ; if successful, quotient in low word of %d0,
                 ; remainder in high word
 jvc.s L1
 jsr _divs       ; assume _divs divides %d0 by %d1, leaving quotient in %d0
 bra.s L2
L1:
 ext.l %d0
L2:

So using the divs.w/divu.w instructions for truncated divides will
require the extra code...

>>   <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.

Hmm,  uberbaum compiles the following code for --target=m68k, -O2 -m5200:

short foo;
extern int bar(int);
int x(void)
{
  if (foo & 0x0080)
    return bar(1);
  else
    return bar(9);
}


into:

#NO_APP
	.file	"test.c"
	.text
	.align	2
	.globl	x
	.type	x, @function
x:
	link.w %fp,#0
	move.b foo+1,%d0	| 58	*m68k.md:752/1
	lsr.l #7,%d0	| 13	lshrsi3
	btst #0,%d0	| 15	*m68k.md:562
	jbeq .L2	| 16	beq
	...

Which could have been shortened to the following(and doesn't use a register):

x:
	link.w %fp,#0
	tst.b foo+1
	jbpl .L2
	...

>>   <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.

This is implemented on m68k/ColdFire for the btst, bclr, bset, bchg
instructions where adjust_address is called to fix the address if the
operand is in memory. See output_xorsi3, output_iorsi3, output_andsi3,
output_btst in gcc/config/m68k/m68k.c


-- 
Peter Barada
peter@the-baradas.com