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

[Bill Currie <bcurrie at tssc dot co dot nz>]

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