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

[Jeffrey A Law <law@cygnus.com>]

  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