From: Bill Currie <bcurrie@tssc.co.nz>
To: law@cygnus.com
Cc: Joern Rennecke <amylaar@cygnus.co.uk>, ak@muc.de, egcs@cygnus.com
Subject: Re: Feature request: ability to describe x86 register halves as contraints.
Date: Fri, 03 Jul 1998 00:12:00 -0000 [thread overview]
Message-ID: <359BF4AB.1229@tssc.co.nz> (raw)
In-Reply-To: <24030.899359722@hurl.cygnus.com>
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
next prev parent reply other threads:[~1998-07-03 0:12 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <359ABD84.2FC4@tssc.co.nz>
1998-07-02 1:39 ` Jeffrey A Law
1998-07-02 1:39 ` Bill Currie
1998-07-02 1:39 ` Jeffrey A Law
1998-07-03 0:12 ` Bill Currie [this message]
1998-07-02 11:02 ` Joern Rennecke
1998-07-02 15:15 ` Bill Currie
1998-07-02 15:15 ` Joern Rennecke
1998-07-01 13:20 Michael Meissner
1998-07-01 20:15 ` Joern Rennecke
-- strict thread matches above, loose matches on Subject: below --
1998-06-29 20:41 ak
1998-06-30 0:42 ` Richard Henderson
1998-06-30 4:50 ` ak
1998-06-30 19:49 ` Alan Modra
1998-06-30 19:49 ` Andreas Kleen
1998-06-30 14:08 ` Jeffrey A Law
1998-06-30 9:24 ` Richard Henderson
1998-06-30 1:02 ` Jeffrey A Law
1998-06-30 11:53 ` Joern Rennecke
1998-06-30 11:53 ` Jeffrey A Law
1998-07-01 3:42 ` Richard Henderson
1998-06-30 15:15 ` Bill Currie
1998-06-30 15:26 ` Jeffrey A Law
1998-06-30 23:15 ` Bill Currie
1998-06-30 19:49 ` Jeffrey A Law
1998-07-01 10:51 ` Joern Rennecke
1998-07-01 10:51 ` Jeffrey A Law
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=359BF4AB.1229@tssc.co.nz \
--to=bcurrie@tssc.co.nz \
--cc=ak@muc.de \
--cc=amylaar@cygnus.co.uk \
--cc=egcs@cygnus.com \
--cc=law@cygnus.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).