From: Jan Hubicka <jh@suse.cz>
To: Richard Henderson <rth@cygnus.com>
Cc: Jan Hubicka <jh@suse.cz>, gcc@gcc.gnu.org
Subject: Re: pre_inc/pre_dec/PUSH_ROUNDING inconsistency
Date: Tue, 18 Jul 2000 01:31:00 -0000 [thread overview]
Message-ID: <20000718103049.B1559@atrey.karlin.mff.cuni.cz> (raw)
In-Reply-To: <20000717160150.A13319@cygnus.com>
> On Mon, Jul 17, 2000 at 02:16:04PM -0700, Richard Henderson wrote:
> > Yes, the TFmode subreg is incorrect. As for the other... well,
> > I guess it's not too bad. I'm not sure what to put in its place.
>
> Alternately, we could just explicitly use subtract plus store.
>
> This is what the x86 backend is going to do anyway, and avoids
> the issue of odd-sized subregs of floating point values. As
> you note, would have caused register allocation problems anyway.
OK, this seems to be best solution I've found so far too.
Perhaps the register allocation problems can be handled by insn patterns
explicitly mentioning the subregs like:
(set (match_operand:DI "push_operand") (subreg:DI (match_operand:SI "general_operand") 0))
But this is kludge and not going to solve problems with memory references (I
believe that combine never construct paradoxical subregs to memory or not?)
The kludge would work - I was playing similar games in one never reviewed patc
hwith mulsihi insn pattern (since this pattern is currently always promoted to
mulhi pattern by combine) and expect the problems in genrecog you perhaps
remember fixing about year ago (the fix was one of my not very lucky patches
especially hard to review)...
Problem is that the explicit subtract plus store method don't fit closely
to the existing way pushes are genrated. Ordinaly mov?i expander is used with
the push_operand in the destination.
Perhaps we can define new "push?i" standard names and add necesary optabs
code to imitate them using push_operand mov?i when not present.
This would not require any changes to existing MD files.
Alternate way is to default into two instruction - the store and the stack
adjustments. This would allow machine description to omit the push paterns
for modes hardware don't implement. Note that for i386 case this should not
be uesable, since even for fp stores we want to use integer push instruction
to store memory, immediates and integer regs. So perhaps the first approach
is easier to implement and better.
What do you think?
Honza
>
>
> r~
next prev parent reply other threads:[~2000-07-18 1:31 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2000-07-16 7:04 Jan Hubicka
2000-07-17 14:07 ` Richard Henderson
2000-07-17 14:10 ` Jan Hubicka
2000-07-17 14:16 ` Richard Henderson
2000-07-17 14:25 ` Jan Hubicka
2000-07-17 16:01 ` Richard Henderson
2000-07-18 1:31 ` Jan Hubicka [this message]
2000-07-28 15:17 ` Jan Hubicka
2000-07-29 12:30 ` Richard Henderson
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=20000718103049.B1559@atrey.karlin.mff.cuni.cz \
--to=jh@suse.cz \
--cc=gcc@gcc.gnu.org \
--cc=rth@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).