Re: Feature request: ability to describe x86 register halves as contraints.

Re: Feature request: ability to describe x86 register halves as contraints.

[Michael Meissner]

| I think we should change SUBREG to count addressable units instead of
| 'words'.  This would also fix some brokenness when there are
| varying register sizes (E.g. floating point wider than integer...)

I would not stop at addressable units, but go for bits.  Either that, or change
things to use {SIGN,ZERO}_EXTRACT, along with some sort of WIDER/CHANGE_TYPE
support.  It might be useful to use a different name than SUBREG, so that you
can identify the broken code.

Re: Feature request: ability to describe x86 register halves as contraints.

[Joern Rennecke]

> | I think we should change SUBREG to count addressable units instead of
> | 'words'.  This would also fix some brokenness when there are
> | varying register sizes (E.g. floating point wider than integer...)
> 
> I would not stop at addressable units, but go for bits.  Either that, or change
> things to use {SIGN,ZERO}_EXTRACT, along with some sort of WIDER/CHANGE_TYPE
> support.  It might be useful to use a different name than SUBREG, so that you
> can identify the broken code.

If we go for bits, we will see the same brokenness as with type sizes - i.e.
overflow when more that 1/16th of the address space is used.

Well, I guess it matters less with access for register parts than with
type sizes...

Re: Feature request: ability to describe x86 register halves as contraints.

[Jeffrey A Law]

  In message <359ABD84.2FC4@tssc.co.nz>you write:
  > Jeffrey A Law wrote:
  > > I guess that would be OK.  I'm still not convinced it's worth the huge
  > > effort though.
  > > jeff
  > 
  > Sometimes I think the amount of effort required is grossly
  > over-estimated (but not allways).
I disagree.  One of the things I do for Cygnus is estimations and
estimation review -- my opinions based on that would tend to be just
the opposite.  While many problems seem easy on the surface, when you
dig deeper you often find fundamental problems that throw off estimations
by  2X-5X.


  > I recently disproved the comment in
  > config/i860/i860.h about the difficulty of gcc supporting cross endian
  > cpu's (ie reg word endian != mem word endian) buy totaly confusing gcc
  > as to what subreg 1 was (I told final.c that subreg 1 was (eg) %r8
  > instead of %r9 :).
And whie this may be working for you, I highly suspect if you dig deeper
you'll find out that all kinds of things eventually break.


  > I haven't submitted any patches yet, because I
  > totally broke the *little* endian i860 (i860.md only) and I'm still
  > finding numberous md bugs that where there at the start (incorrect
  > constraints etc), and I still have to forward port my patches to the
  > latest CVS sources.
The i860 port is probably buggy as hell.  Nobody's working on it at all.


  > One question, would the following work, or would it break insn
  > recognition?
  > 
  > (define_expand "fix_truncdfsi2"
  >   ;; This first insn produces a double-word value
  >   ;; in which only the low word is valid.
  >   [(set (match_dup 2)
  > 	(fix:DI (fix:DF (match_operand:DF 1 "register_operand" "f"))))
  >    (set (match_operand:SI 0 "register_operand" "=f")
  > 	(match_dup 3))] /*this used to be (subreg (SI (match_dup 2) 1)*/
  >   ""
  >   "
  > {
  >   operands[2] = gen_reg_rtx (DImode);
  >   operands[3] = gen_rtx_SUBREG (SImode, operands[2], WORDS_BIG_ENDIAN);
  > }")
  > 
  > I would like to do this so i860 endian selection can be a target switch.
I would think this will work as long as you have appropriate matchers.

However, I'm curious how you deal with memory subregs or register
subregs that get spilled, then loaded from memory.  I get the
impression that how the word of a subreg is interpreted changes based
on what the inner object is.

jeff

Re: Feature request: ability to describe x86 register halves as contraints.

[Bill Currie]

Jeffrey A Law wrote:
>   > Sometimes I think the amount of effort required is grossly
>   > over-estimated (but not allways).
> I disagree.  One of the things I do for Cygnus is estimations and
> estimation review -- my opinions based on that would tend to be just
> the opposite.  While many problems seem easy on the surface, when you
> dig deeper you often find fundamental problems that throw off estimations
> by  2X-5X.

Sorry.  However, I found that I didn't have to change gcc's assumptions
about register/memory ordering to get my port to work.

> And whie this may be working for you, I highly suspect if you dig deeper
> you'll find out that all kinds of things eventually break.

My initial attempts did exactly that.  I did the silly thing of trying
to cross the registers over when going from fp<->int register.
everything blew up very badly.

However, I get a successfull stage3 build and compare.  Does that count?

> The i860 port is probably buggy as hell.  Nobody's working on it at all.

In that case, should I submit my patches anyway so at least they won't
get lost?  Also, I would like feedback on what I've done from
knowledgable people.

> I would think this will work as long as you have appropriate matchers.

There are already matchers, so I'll just give it a go and see what
happens.

> However, I'm curious how you deal with memory subregs or register
> subregs that get spilled, then loaded from memory.

Hmm... now, I could have missed something, but the existing i860 md file
has relatively few references to subregs.  The only time I had any real
problems was getting MULSI3 to work cleanly.  This required hacking in
use of strict_low_part, probably to get around this very issue.  I might
even find a cleaner solution.

Also, I could be very wrong (especially because I'm not too sure what
spilling is), but how often do subregs get spilled?  Hmm, just realised
you may be referring to when reload.c strips the subreg info if the
subreg is 0. I told push_reload (? bloody big functions) not to strip
the subreg info if REG_WORDS_BIG_ENDIAN != WORDS_BIG_ENDIAN.

> I get the
> impression that how the word of a subreg is interpreted changes based
> on what the inner object is.

Do you mean whether it's a REG or a MEM object?  Yes, that's exactly
what I do in final.c as it is selecting the register name.

Here's the my patch to final.c that implements this.  (there may still
be problems with non DI/DF instances, but I haven't encountered any
yet).

diff -urN rgcs-1.0.3a/gcc/final.c egcs-ftx/gcc/final.c
--- foobar/final.c      Sun Oct 19 04:22:17 1997
+++ egcs-ftx/gcc/final.c        Wed Jun 24 16:05:32 1998
@@ -69,6 +69,10 @@
 #include "output.h"
 #include "except.h"
 
+#ifndef REG_WORDS_BIG_ENDIAN
+#define REG_WORDS_BIG_ENDIAN WORDS_BIG_ENDIAN
+#endif
+
 /* Get N_SLINE and N_SOL from stab.h if we can expect the file to
exist.  */
 #if defined (DBX_DEBUGGING_INFO) || defined (XCOFF_DEBUGGING_INFO)
 #if defined (USG) || defined (NO_STAB_H)
@@ -2305,8 +2309,19 @@
   if (GET_CODE (y) == REG)
     {
       /* If the containing reg really gets a hard reg, so do we.  */
-      PUT_CODE (x, REG);
-      REGNO (x) = REGNO (y) + SUBREG_WORD (x);
+      if ((REG_WORDS_BIG_ENDIAN != WORDS_BIG_ENDIAN) &&
+         (GET_MODE (x) != DImode) &&
+         (GET_MODE (x) != DFmode) &&
+         (GET_MODE (y) == DImode || GET_MODE (y) == DFmode))
+        {
+         PUT_CODE (x, REG);
+         REGNO (x) = REGNO (y) + 1 - SUBREG_WORD (x);
+       }
+      else
+        {
+         PUT_CODE (x, REG);
+         REGNO (x) = REGNO (y) + SUBREG_WORD (x);
+        }
     }
   else if (GET_CODE (y) == MEM)
     {

-- 
Leave others their otherness

Re: Feature request: ability to describe x86 register halves as contraints.

[Jeffrey A Law]

  In message < 359AFFE1.26F8@tssc.co.nz >you write:
  > However, I get a successfull stage3 build and compare.  Does that count?
Not really :-)  You wouldn't believe the things I've seen pass 3-stage
the testsuite, commercial testsuites, etc.


  > In that case, should I submit my patches anyway so at least they won't
  > get lost?  Also, I would like feedback on what I've done from
  > knowledgable people.
Yes they would be greatly appreciated.  If at all possible you should
send multiple patches -- one for each problem you encountered.  Since
few of us know the i860 all that well, it would be quite helpful if
you could describe the problem and how your solution fixes the problem
so that we can better evaluate the change.

It may also be the case that we'll need a copyright assignment from you
to use the changes -- depends on how big they are as a whole.

  > > However, I'm curious how you deal with memory subregs or register
  > > subregs that get spilled, then loaded from memory.
  > 
  > Hmm... now, I could have missed something, but the existing i860 md file
  > has relatively few references to subregs.  The only time I had any real
  > problems was getting MULSI3 to work cleanly.  This required hacking in
  > use of strict_low_part, probably to get around this very issue.  I might
  > even find a cleaner solution.
References to subregs mostly created by the compiler totally outside
the control of the backend.  Furthermore, if you have predicates that
accept a "register_operand", then they also accept subregs.  As would
"general_operand".

So consider a AND operation of two DImode registers (call them X & Y))
The compiler may generate code like this:

(set (reg:SI 0) (subreg:SI (reg:DI source1) 0)))
(set (reg:SI 1) (subreg:SI (reg:DI source1) 1)))
(set (reg:SI 2) (subreg:SI (reg:DI source2) 0)))
(set (reg:SI 3) (subreg:SI (reg:DI source2) 1)))

(set (subreg:SI (reg:DI target) 0)) (and:SI (reg:SI 0) (reg:SI 2))
(set (subreg:SI (reg:DI target) 1)) (and:SI (reg:SI 1) (reg:SI 4))

In this case word order doesn't matter.  In other cases it will
(consider addition) and if some of the regs get spilled to memory
you'll change the meaning of the code because the meaning of the
subreg changes.

  > Also, I could be very wrong (especially because I'm not too sure what
  > spilling is), but how often do subregs get spilled?
Not sure how to answer that. :-)  They do get spilled.  Since there's
generally fewer subregs than regs the total number of spills is smaller.
However, I suspect the percentage of subregs that gets spilled is high.

  > Hmm, just realised
  > you may be referring to when reload.c strips the subreg info if the
  > subreg is 0. I told push_reload (? bloody big functions) not to strip
  > the subreg info if REG_WORDS_BIG_ENDIAN != WORDS_BIG_ENDIAN.
It's more than that.   :-)

For example the compiler could have (subreg:SI (reg:DI) 1); then consider
what happens in the reg gets spilled to the stack -- you'll end up
with (subreg:SI (mem:DI) 1) which has a different meaning.

reload can (and will) perform direct replacements of a REG with a MEM
expression.  Other passes may do this too, but the register alloctors
and reload do it more than other passes.  When this happens the meaning
of the code changes because the meaning of SUBREG changes depending on
what item is inside the SUBREG.


  > > impression that how the word of a subreg is interpreted changes based
  > > on what the inner object is.
  > 
  > Do you mean whether it's a REG or a MEM object?  Yes, that's exactly
  > what I do in final.c as it is selecting the register name.
Ouch!  Danger.  Danger.  Danger.  This is not safe.  See above about
replacement of REG with MEM expressions.


jeff

Re: Feature request: ability to describe x86 register halves as contraints.

[Bill Currie]

Jeffrey A Law wrote:
> 
>   In message < 359AFFE1.26F8@tssc.co.nz >you write:
>   > However, I get a successfull stage3 build and compare.  Does that count?
> Not really :-)  You wouldn't believe the things I've seen pass 3-stage
> the testsuite, commercial testsuites, etc.

Actually, I've been getting problems still (broken long long constants
at the moment), so I believe you.


> Yes they would be greatly appreciated.  If at all possible you should
> send multiple patches -- one for each problem you encountered.  Since
> few of us know the i860 all that well, it would be quite helpful if
> you could describe the problem and how your solution fixes the problem
> so that we can better evaluate the change.

Ok, I'll get started on splitting up my diff file and writing up what
each set of diffs does.

> It may also be the case that we'll need a copyright assignment from you
> to use the changes -- depends on how big they are as a whole.

Not a problem.  I already have verbal permission from my employer, so
I'll just need the forms (20k of diffs).

> References to subregs mostly created by the compiler totally outside
> the control of the backend.  Furthermore, if you have predicates that
> accept a "register_operand", then they also accept subregs.  As would
> "general_operand".

Yeah, I think it was that which helped me come to my solution.

> So consider a AND operation of two DImode registers (call them X & Y))
> The compiler may generate code like this:
> 
> (set (reg:SI 0) (subreg:SI (reg:DI source1) 0)))
> (set (reg:SI 1) (subreg:SI (reg:DI source1) 1)))
> (set (reg:SI 2) (subreg:SI (reg:DI source2) 0)))
> (set (reg:SI 3) (subreg:SI (reg:DI source2) 1)))
> 
> (set (subreg:SI (reg:DI target) 0)) (and:SI (reg:SI 0) (reg:SI 2))
> (set (subreg:SI (reg:DI target) 1)) (and:SI (reg:SI 1) (reg:SI 4))

Bletch.  And I believe the i860 WILL do that as there aren't any 64 bit
and instructions.  However, this doesn't cause a problem.

> In this case word order doesn't matter.  In other cases it will
> (consider addition) and if some of the regs get spilled to memory
> you'll change the meaning of the code because the meaning of the
> subreg changes.

I've only ever seen whole regs getting spilled (if I understand
spilling).

>   > Also, I could be very wrong (especially because I'm not too sure what
>   > spilling is), but how often do subregs get spilled?
> Not sure how to answer that. :-)  They do get spilled.  Since there's
> generally fewer subregs than regs the total number of spills is smaller.
> However, I suspect the percentage of subregs that gets spilled is high.
> 
>   > Hmm, just realised
>   > you may be referring to when reload.c strips the subreg info if the
>   > subreg is 0. I told push_reload (? bloody big functions) not to strip
>   > the subreg info if REG_WORDS_BIG_ENDIAN != WORDS_BIG_ENDIAN.
> It's more than that.   :-)
> 
> For example the compiler could have (subreg:SI (reg:DI) 1); then consider
> what happens in the reg gets spilled to the stack -- you'll end up
> with (subreg:SI (mem:DI) 1) which has a different meaning.
> 
> reload can (and will) perform direct replacements of a REG with a MEM
> expression.  Other passes may do this too, but the register alloctors
> and reload do it more than other passes.  When this happens the meaning
> of the code changes because the meaning of SUBREG changes depending on
> what item is inside the SUBREG.

Ah, we seem to be mis-communicating.  I do not change the meaning of a
SUBREG until it's time to actually emit the assembly code.  The only
change to SUBREG's meaning I make is the order of the subregs within a
DI *register* pair.

>   > > impression that how the word of a subreg is interpreted changes based
>   > > on what the inner object is.
>   >
>   > Do you mean whether it's a REG or a MEM object?  Yes, that's exactly
>   > what I do in final.c as it is selecting the register name.
> Ouch!  Danger.  Danger.  Danger.  This is not safe.  See above about
> replacement of REG with MEM expressions.

But that is done long before printing the assembly code, is it not?

NOTE: I *HAVE* seen my SUBREG definition hacking causing problems, *BUT*
that (so far) has been caused by incorrect constraints on insns, which I
promptly fixed as I found them.

Somehow, I think I will have to submit those patches (with *DETAILED*
explanations:) just to show that I think I think I sortof know what I'm
doing:)  I'll spend the weeked forward porting my patches to the most my
recent CVS grab (2amNZST daily) and writing them up (Friday here at the
moment:).

Bill
-- 
Leave others their otherness

Re: Feature request: ability to describe x86 register halves as contraints.

[Joern Rennecke]

Why don't you just re-number the registers so that their endianness matches
that of memory?

Re: Feature request: ability to describe x86 register halves as contraints.

[Bill Currie]

Joern Rennecke wrote:
> 
> Why don't you just re-number the registers so that their endianness matches
> that of memory?

I'd thought of that, but the problem is the floating point regs.  This
would work nicely for the integer registers, but the i860 groups the fp
regs into pairs for DI mode regs:

	MSW  LSW
	%f1  %f0
	%f3  %f2
	...
	%f31 %f30

And the pairs must always be referred to by the lower regiters (%f0, %f2
... %f30).

Bill
-- 
Leave others their otherness

Re: Feature request: ability to describe x86 register halves as contraints.

[Joern Rennecke]

> I'd thought of that, but the problem is the floating point regs.  This
> would work nicely for the integer registers, but the i860 groups the fp
> regs into pairs for DI mode regs:
> 
> 	MSW  LSW
> 	%f1  %f0
> 	%f3  %f2
> 	...
> 	%f31 %f30
> 
> And the pairs must always be referred to by the lower regiters (%f0, %f2
> ... %f30).

You would have then to use some special code to print register pairs.

Feature request: ability to describe x86 register halves as contraints.

[ak]

Hallo, 

Egcs does not handle x86 register halves (al/ah etc.) well. Although
it is able to turn (x & 0xFF) into an access to the rL register, there
is no way to trick it into generating write access to rH registers
(neither union { char h,l; short val } x; x.h = 1; nor and/shift/or tricks
work). 

It is often good for the code to use the register halves, because in 
algorithms which operate on 8 values (e.g. some ciphers) the ability
to access register halves effectively adds 4 more 8bit registers.
Because the x86 CPUs are so register starved this can speed some inner
loops up considerably.

I understand that making gcc do this automatically is a non-trivial
amount of work. 

To optimize a critical inner loop I've resorted to use inline assembly
in some critical computations to work directly on the 8bit halves. 
Unfortunately I've hit a limitation of the gcc constraints language
now. There is no way to describe:

"Give me a 16bit register, but insert the high/low byte form of the register-
name here." 

e.g.  it should pass in a 16bit value in a register like AX, but insert
into the assembler template AH or AL depending on a special flag. 

The only way to do this is to use fixed input registers and hardcode the 
register halves. Unfortunately this adds some compiler version dependencies
to my code, and also limits the possibilities of the compiler to do other
optimizations. 

Is it possible to add such an extension to the constraints language? 
Hopefully only minimal changes should be needed for this. 

-Andi

Re: Feature request: ability to describe x86 register halves as contraints.

[Richard Henderson]

On Mon, Jun 29, 1998 at 06:44:04PM +0200, ak@muc.de wrote:
> The only way to do this is to use fixed input registers and hardcode the 
> register halves. Unfortunately this adds some compiler version dependencies
> to my code, and also limits the possibilities of the compiler to do other
> optimizations. 

Incorrect:

   b -- print the QImode name of the register for the indicated operand.
        %b0 would print %al if operands[0] is reg 0.
   w --  likewise, print the HImode name of the register.
   k --  likewise, print the SImode name of the register.
   h --  print the QImode name for a "high" register, either ah, bh, ch or dh.

So:

	asm ("# %0 %b0 %h0 %w0 %k0" : : "q"(x));

yields

	# %eax %al %ah %ax %eax


r~

Re: Feature request: ability to describe x86 register halves as contraints.

[ak]

On Tue, Jun 30, 1998 at 09:46:29AM +0200, Richard Henderson wrote:
> On Mon, Jun 29, 1998 at 06:44:04PM +0200, ak@muc.de wrote:
> > The only way to do this is to use fixed input registers and hardcode the 
> > register halves. Unfortunately this adds some compiler version dependencies
> > to my code, and also limits the possibilities of the compiler to do other
> > optimizations. 
> 
> Incorrect:
> 
>    b -- print the QImode name of the register for the indicated operand.
>         %b0 would print %al if operands[0] is reg 0.
>    w --  likewise, print the HImode name of the register.
>    k --  likewise, print the SImode name of the register.
>    h --  print the QImode name for a "high" register, either ah, bh, ch or dh.
> 
> So:
> 
> 	asm ("# %0 %b0 %h0 %w0 %k0" : : "q"(x));
> 
> yields
> 
> 	# %eax %al %ah %ax %eax

Ok, I feel stupid now, but to my defense I must say that this is not 
documented in the info pages. 

Thank you.

-Andi

Re: Feature request: ability to describe x86 register halves as contraints.

[Alan Modra]

On Tue, 30 Jun 1998 ak@muc.de wrote:

> > 	asm ("# %0 %b0 %h0 %w0 %k0" : : "q"(x));
> > 
> > yields
> > 
> > 	# %eax %al %ah %ax %eax
> 
> Ok, I feel stupid now, but to my defense I must say that this is not 
> documented in the info pages.

Yes, you have to dig into i386.md

Colin Plumb <colin@nyx.net> wrote a really good, tutorial style,
description of x86 constraints.  If you ask him, I guess he'd be happy to
send it to you.  His tutorial really ought to be part of egcs
documentation.

Re: Feature request: ability to describe x86 register halves as contraints.

[Andreas Kleen]

On Wed, Jul 01, 1998 at 02:44:02AM +0200, Alan Modra wrote:
> 
> On Tue, 30 Jun 1998 ak@muc.de wrote:
> 
> > > 	asm ("# %0 %b0 %h0 %w0 %k0" : : "q"(x));
> > > 
> > > yields
> > > 
> > > 	# %eax %al %ah %ax %eax
> > 
> > Ok, I feel stupid now, but to my defense I must say that this is not 
> > documented in the info pages.
> 
> Yes, you have to dig into i386.md
> 
> Colin Plumb <colin@nyx.net> wrote a really good, tutorial style,
> description of x86 constraints.  If you ask him, I guess he'd be happy to
> send it to you.  His tutorial really ought to be part of egcs
> documentation.

I have his tutorial, but I didn't look there (mea culpa)


-Andi

Re: Feature request: ability to describe x86 register halves as contraints.

[Jeffrey A Law]

  In message < 19980630004629.A20825@dot.cygnus.com >you write:
  > On Mon, Jun 29, 1998 at 06:44:04PM +0200, ak@muc.de wrote:
  > > The only way to do this is to use fixed input registers and hardcode the 
  > > register halves. Unfortunately this adds some compiler version dependencies
  > > to my code, and also limits the possibilities of the compiler to do other
  > > optimizations. 
  > 
  > Incorrect:
  > 
  >    b -- print the QImode name of the register for the indicated operand.
  >         %b0 would print %al if operands[0] is reg 0.
  >    w --  likewise, print the HImode name of the register.
  >    k --  likewise, print the SImode name of the register.
  >    h --  print the QImode name for a "high" register, either ah, bh, ch or dh.> 
And does the compiler just assume that the whole register is trashed
since it doesn't ever look at the asm strings?

Maybe we're talking about two different issues.

jeff

Re: Feature request: ability to describe x86 register halves as contraints.

[Richard Henderson]

On Tue, Jun 30, 1998 at 10:08:52AM -0600, Jeffrey A Law wrote:
> And does the compiler just assume that the whole register is trashed
> since it doesn't ever look at the asm strings?

Yes.  


r~

Re: Feature request: ability to describe x86 register halves as contraints.

[Jeffrey A Law]

  In message < 19980629184404.62482@kali.lrz-muenchen.de >you write:
  > Egcs does not handle x86 register halves (al/ah etc.) well. Although
  > it is able to turn (x & 0xFF) into an access to the rL register, there
  > is no way to trick it into generating write access to rH registers
  > (neither union { char h,l; short val } x; x.h = 1; nor and/shift/or tricks
  > work). 
The lack of aggressive use of byte/half sized registers is probably
a direct result of the x86 target files being designed as a 32bit
target.

It claims registers are 32bits wide and that the size of a word is
32bits.

To get more aggressive optimziation of these smaller values you'd have
to change the size of registers.  A *large* task.  I looked into doing
it for the H8 a while back and decided it was not worth the effort.

One could argue that gcc should have better mechanisms to deal with
partial registers.

Such concepts would help many older ports like the x86, m68k, h8, etc.

[ ... ]
  > Is it possible to add such an extension to the constraints language? 
  > Hopefully only minimal changes should be needed for this. 
First there'd have to be a way to describe hi/lo halves of registers
in RTL.  I'm not aware of any such mechanism.

jeff

Re: Feature request: ability to describe x86 register halves as contraints.

[Joern Rennecke]

>   > Is it possible to add such an extension to the constraints language? 
>   > Hopefully only minimal changes should be needed for this. 
> First there'd have to be a way to describe hi/lo halves of registers
> in RTL.  I'm not aware of any such mechanism.

I think we should change SUBREG to count addressable units instead of
'words'.  This would also fix some brokenness when there are
varying register sizes (E.g. floating point wider than integer...)

Re: Feature request: ability to describe x86 register halves as contraints.

[Jeffrey A Law]

  In message < 199806301655.RAA04324@phal.cygnus.co.uk >you write:
  > >   > Is it possible to add such an extension to the constraints language? 
  > >   > Hopefully only minimal changes should be needed for this. 
  > > First there'd have to be a way to describe hi/lo halves of registers
  > > in RTL.  I'm not aware of any such mechanism.
  > 
  > I think we should change SUBREG to count addressable units instead of
  > 'words'.  This would also fix some brokenness when there are
  > varying register sizes (E.g. floating point wider than integer...)
I'm not sure I'd recommend changing the meaning of SUBREG -- we might
be better off with a new RTX for this kindof thing.

jeff

Re: Feature request: ability to describe x86 register halves as contraints.

[Richard Henderson]

On Tue, Jun 30, 1998 at 11:01:32AM -0600, Jeffrey A Law wrote:
>   > I think we should change SUBREG to count addressable units instead of
>   > 'words'.  This would also fix some brokenness when there are
>   > varying register sizes (E.g. floating point wider than integer...)
> I'm not sure I'd recommend changing the meaning of SUBREG -- we might
> be better off with a new RTX for this kindof thing.

Actually, in the context of sparc64 lossage, Jim suggested
that the proper solution was to fix subreg part number be
unrelated anything target specific, so that a subreg would
mean exactly the same thing on all ports.

He of course added that it would be a stunning amount of work.


r~

Re: Feature request: ability to describe x86 register halves as contraints.

[Bill Currie]

Jeffrey A Law wrote:
> First there'd have to be a way to describe hi/lo halves of registers
> in RTL.  I'm not aware of any such mechanism.

Couldn't (subreg:QI (reg:HI 0) 1) or (subreg:QI (reg:SI 0) 1) be used to
represent AH?  Trouble is, someone will have to teach egcs to use such
constructs (I'm not well versed on the operation of trees yet,
especially tree->rtl conversion)

Also, how difficult would it be to add eiter a new machine mode or a new
flag/interpretation of existing flags to represent halves of registers?

Bill
-- 
Leave others their otherness

Re: Feature request: ability to describe x86 register halves as contraints.

[Jeffrey A Law]

  In message <359962C1.6A80@tssc.co.nz>you write:
  > Jeffrey A Law wrote:
  > > First there'd have to be a way to describe hi/lo halves of registers
  > > in RTL.  I'm not aware of any such mechanism.
  > 
  > Couldn't (subreg:QI (reg:HI 0) 1) or (subreg:QI (reg:SI 0) 1) be used to
  > represent AH?  Trouble is, someone will have to teach egcs to use such
  > constructs (I'm not well versed on the operation of trees yet,
  > especially tree->rtl conversion)
Nope -- the constant at the end refers to a word sized object -- on
the x86 words are 32bits.

SUBREGs already have a well defined meaning.  I don't suggest overloading
another meaning on them.

  > Also, how difficult would it be to add eiter a new machine mode or a new
  > flag/interpretation of existing flags to represent halves of registers?
It's not a question of modes or flags, but of how to represent to the
compiler via the RTL how to access parts of a register.

jeff

Re: Feature request: ability to describe x86 register halves as contraints.

[Bill Currie]

Jeffrey A Law wrote:
> Nope -- the constant at the end refers to a word sized object -- on
> the x86 words are 32bits.

Ouch, had to try.

> SUBREGs already have a well defined meaning.  I don't suggest overloading
> another meaning on them.

I didn't think overloading subregs was desirable.

> It's not a question of modes or flags, but of how to represent to the
> compiler via the RTL how to access parts of a register.

I'm not sure what you mean. I'm starting to think that this comment is
related to your comment above about the constant reffering to word sized
objects.  I just had the thought of defining a whole new varian of
subreg, BUT then I realized there's still the problem of what to do with
it (as in getting the compiler to us it at the right times).

Does egcs not support the upper half of ANY register size (<=word, I
know DI upper half is accessable) on any machine?

I'm begginning to get more interested in this idea (I've been thinking
about it off and on for a few years, but I've only recently learned
enough to know what you're talking about).

Bill
-- 
Leave others their otherness

Re: Feature request: ability to describe x86 register halves as contraints.

[Jeffrey A Law]

  In message < 35996BF7.5474@tssc.co.nz >you write:
  > I'm not sure what you mean. I'm starting to think that this comment is
  > related to your comment above about the constant reffering to word sized
  > objects.  I just had the thought of defining a whole new varian of
  > subreg, BUT then I realized there's still the problem of what to do with
  > it (as in getting the compiler to us it at the right times).
You need something similar to a SUBREG, but with semantics to describe
the situation you want to address.

Seems to me it would need an expression and two integer args -- the
expresion is the data item (ie a register) that we want to operate
on, then start offset (in bits) and width (in bits).

Hmmm, I think we just described the bitfield support :-)

Maybe you could make it handle the stuff you're trying to do.


  > Does egcs not support the upper half of ANY register size (<=word, I
  > know DI upper half is accessable) on any machine?
Not that I'm aware of.

jeff

Re: Feature request: ability to describe x86 register halves as contraints.

[Joern Rennecke]

> Seems to me it would need an expression and two integer args -- the
> expresion is the data item (ie a register) that we want to operate
> on, then start offset (in bits) and width (in bits).

Why is a mode not good enough to represent the size?

Re: Feature request: ability to describe x86 register halves as contraints.

[Jeffrey A Law]

  In message < 199807011632.RAA30645@phal.cygnus.co.uk >you write:
  > > Seems to me it would need an expression and two integer args -- the
  > > expresion is the data item (ie a register) that we want to operate
  > > on, then start offset (in bits) and width (in bits).
  > 
  > Why is a mode not good enough to represent the size?
I guess that would be OK.  I'm still not convinced it's worth the huge
effort though.
jeff