More OLD PROBLEMS problems

More OLD PROBLEMS problems

[Steven Bosscher]

Hi,

Can anyone give more details about the following listed OLD PROBLEMS
on http://gcc.gnu.org/projects/intex.html.  I'd like to get rid of
those that lack a clear explanation of the actual problem.  If nobody
knows what the problem is/was, I'll post a patch to remove the items
as I really don't see any point in listing problems that nobody knows
anything about.

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:

char a; short b;
short foo (void) { return a * b; }

--> .rtl (gcc 3.3.5):
                                                                                                  
(insn 10 9 11 (nil) (set (reg:QI 61)
        (mem/f:QI (symbol_ref:SI ("a")) [0 a+0 S1 A8])) -1 (nil)
    (nil))
                                                                                        
(insn 11 10 12 (nil) (set (reg:HI 60)
        (sign_extend:HI (reg:QI 61))) -1 (nil)
    (nil))
                                                                                        
(insn 12 11 13 (nil) (set (reg:HI 62)
        (mem/f:HI (symbol_ref:SI ("b")) [2 b+0 S2 A16])) -1 (nil)
    (nil))
                                                                                        
(insn 13 12 14 (nil) (parallel [
            (set (reg:HI 63)
                (mult:HI (reg:HI 60)
                    (reg:HI 62)))
            (clobber (reg:CC 17 flags))
        ]) -1 (nil)
    (nil))

--> asm:

foo:
        movsbw  a,%ax
        imulw   b, %ax
        cwtl
        ret

Which looks pretty OK to me.  Is there any target for which this
would not work?  Any objections to me removing this "problem"?



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



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



  <li value="69">Define the floating point converting arithmetic
  instructions for the 68881.</li>

Which instructions are this?  Are they implemented?  (Schwab? ;-)



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



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



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


Help me out here!  :-)

Gr.
Steven

Re: 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 -&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.

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

Re: More OLD PROBLEMS problems

[Peter Barada]

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

Re: More OLD PROBLEMS problems

[Ian Lance Taylor]

Peter Barada <peter@the-baradas.com> writes:

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

I think the idea of the original suggestion in the PROBLEMS file was
that if the result of the division is being stored in a 16-bit
variable, then you don't have to worry about the overflow check.
    int a;
    short b;
    short c = a / b;


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

File an report in bugzilla, I think.


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

Cool.

Ian

Re: More OLD PROBLEMS problems

[Gerald Pfeifer]

Steven, 

I suggest to go ahead and remove all entries where Ian clearly indicated 
these to be obsolete, similarly for cases where others will provide feed-
back.

Gerald

Re: More OLD PROBLEMS problems

[Peter Barada]

>I suggest to go ahead and remove all entries where Ian clearly indicated 
>these to be obsolete, similarly for cases where others will provide feed-
>back.

Hopefully not the one that I commented about :)

I'm currently pulling together a testcase(for --target=m68k-elf) that
shows  where it works and fails, and will submit a bug.

-- 
Peter Barada
peter@the-baradas.com

Re: More OLD PROBLEMS problems

[Steven Bosscher]

On Dec 12, 2004 01:13 AM, Peter Barada <peter@the-baradas.com> wrote:

> 
> >I suggest to go ahead and remove all entries where Ian clearly indicated 
> >these to be obsolete, similarly for cases where others will provide feed-
> >back.
> 
> Hopefully not the one that I commented about :)
>
> I'm currently pulling together a testcase(for --target=m68k-elf) that
> shows  where it works and fails, and will submit a bug.

My original plan was to move all the remaining m68k "problems", including
the ones you commented on, to a page with "projects for the m68k".
Is that OK with you?

Gr.
Steven

Re: More OLD PROBLEMS problems

[Ian Lance Taylor]

Steven Bosscher <stevenb@suse.de> writes:

> My original plan was to move all the remaining m68k "problems", including
> the ones you commented on, to a page with "projects for the m68k".
> Is that OK with you?

I think it would be better to just file all the ones which have not
yet been fixed in bugzilla.  That will make it easier to handle them
individually.

Ian

Re: More OLD PROBLEMS problems

[Peter Barada]

>> >I suggest to go ahead and remove all entries where Ian clearly indicated 
>> >these to be obsolete, similarly for cases where others will provide feed-
>> >back.
>> 
>> Hopefully not the one that I commented about :)
>>
>> I'm currently pulling together a testcase(for --target=m68k-elf) that
>> shows  where it works and fails, and will submit a bug.
>
>My original plan was to move all the remaining m68k "problems", including
>the ones you commented on, to a page with "projects for the m68k".
>Is that OK with you?

Ah, I read "remove all entries" as being that they would get dropped
on the floor.  Moving them to their own m68k/ColdFire page sounds
fine.

-- 
Peter Barada
peter@the-baradas.com

[wwwdocs] Re: More OLD PROBLEMS problems

[Steven Bosscher]

On Sunday 12 December 2004 02:45, Peter Barada wrote:
> >My original plan was to move all the remaining m68k "problems", including
> >the ones you commented on, to a page with "projects for the m68k".
> >Is that OK with you?
>
> Ah, I read "remove all entries" as being that they would get dropped
> on the floor.  Moving them to their own m68k/ColdFire page sounds
> fine.

Dropping them on the floor would not even be unreasonable, you know,
as clearly nobody cares enough about the issues mentioned there to
do anything about it.  At least, nobody in the last 15 years or so,
because that is how long these items have been around without anyone
fixing the problems :-)

Having bugs filed for the remaining issues would be better IMO than
creating an m68k projects page.  Since the "old problems" do not
have test cases, and I don't understand them all, I decided to move
them to a separate web page instead of to /dev/null.  But if you do
understand the problems and you can file bugs (with test cases!) for
each of them, I think that would be much better.

In the mean time, the attached patch removes the items that Ian
commented on.  OK?

There are 9 remaining "old problems", 4 of which are m68k specific.
For the rest, let's see if we can get enhancement requests filed.

Gr.
Steven

Index: index.html
===================================================================
RCS file: /cvs/gcc/wwwdocs/htdocs/projects/index.html,v
retrieving revision 1.53
diff -u -3 -p -r1.53 index.html
--- index.html	3 Dec 2004 19:57:11 -0000	1.53
+++ index.html	12 Dec 2004 11:44:49 -0000
@@ -551,20 +551,6 @@ gcc-patches to remove such analysed entr
   <p>If ordering of operands is improved, many more such cases will be
   generated from typical array accesses.</p></li>
 
-  <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>
-
-  <li value="39">Hack expanding of division to notice cases for long -&gt;
-  short division.</li>
-
-  <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>
-
   <li value="63">Potential problem in <code>cc_status.value2</code>, if it
   ever activates itself after a two-address subtraction (which currently
   cannot happen).  It is supposed to compare the current value of the
@@ -572,18 +558,12 @@ gcc-patches to remove such analysed entr
   subtraction, equivalent to comparing the previous value of the
   destination.</li>
 
-  <li value="69">Define the floating point converting arithmetic
-  instructions for the 68881.</li>
-
   <li value="85">pea can force a value to be reloaded into an areg which
   can make it worse than separate adding and pushing.  This can only
   happen for adding something within addql range and it only loses if
   the qty becomes dead at that point so it can be added to with no
   copying.</li>
 
-  <li value="96">Can do SImode bitfield insns without reloading, but must
-  alter the operands in special ways.</li>
-
   <li value="108">Can speed up flow analysis by making a table saying
   which register is set and which registers are used by each instruction
   that only sets one register and only uses two.  This way avoid the
@@ -599,9 +579,6 @@ gcc-patches to remove such analysed entr
   those insns.  Ok if insns being discarded are known 1 to 1.  An andl
   #1 after a seq is 1 to 1, but how should compiler know that?</li>
 
-  <li value="112">Can convert float to unsigned int by subtracting a
-  constant, converting to signed int, and changing the sign bit.</li>
-
   <li value="117">Any number of slow zero-extensions in one loop, that
   have their clr insns moved out of the loop, can share one register if
   their original life spans are disjoint.  But it may be hard to be sure

Re: [wwwdocs] Re: More OLD PROBLEMS problems

[Gerald Pfeifer]

On Sun, 12 Dec 2004, Steven Bosscher wrote:
> Having bugs filed for the remaining issues would be better IMO than
> creating an m68k projects page.

Agreed.

> In the mean time, the attached patch removes the items that Ian
> commented on.  OK?

Yup.

Gerald