From: Jan Hubicka <jh@suse.cz>
To: gcc@gcc.gnu.org, rth@cygnus.com
Subject: pre_inc/pre_dec/PUSH_ROUNDING inconsistency
Date: Sun, 16 Jul 2000 07:04:00 -0000 [thread overview]
Message-ID: <20000716160420.A26370@atrey.karlin.mff.cuni.cz> (raw)
Hi,
It seems to me, that there is imporntant inconcistency between pre_inc/pre_dec
operators and the PUSH_ROUNDING macro. The documentation says:
`(pre_dec:M X)'
Represents the side effect of decrementing X by a standard amount
and represents also the value that X has after being decremented.
X must be a `reg' or `mem', but most machines allow only a `reg'.
M must be the machine mode for pointers on the machine in use.
The amount X is decremented by is the length in bytes of the
machine mode of the containing memory reference of which this
expression serves as the address. Here is an example of its use:
(mem:DF (pre_dec:SI (reg:SI 39)))
This says to decrement pseudo register 39 by the length of a
`DFmode' value and use the result to address a `DFmode' value.
so it seems to suggest, that pre_dec always decrements by the size of mode. On
the other hand, when I define PUSH_ROUDNING to round up everything to 8 (as I
do in md file I am working on), since I want all arguments to be aligned by
that amount and I don't want calls.c to emit stack pointer arithmetics for
pading of 32bit 'int' arguments, I get following instructions to push
32bit quantities (these are constructed mostly by emit_push_insn and are
out of scope of machine description, that gets just those operands to move
pattern):
(set (mem/f:SI (pre_dec:DI (reg:DI 7 sp)) (const_int 1)))
and code handling function calls expect the to be "push" operation and thus
adjust stack by PUSH_ROUNDING (4) size (that is 8),
but since mem mode is SImode, other parts of compiler (such as
combine_stack_adjustements) expect the sp value to be decremended by
size of SImode, thus 4 causing many missoptimizations.
What do you think is the correct way off this situation? Modify the
emit_push_insn in explow.c to change push insn representation for example
to something like:
(set (mem/f:DI (pre_dec:DI (reg:DI sp)) (subreg:DI val)))
since thats what the instruction does?
(can I easilly convert number of bytes returned by push_rounding to mode?)
or some other solution? (I guess it is not good idea to convert rest
of compiler to use PUSH_ROUDNING macro for autoinc/dec arithmetics).
Quick solution would be probably to promote all operands to DImodes, but
I would like to avoid zero/sign extending on caller side and I would run
into problems with XFmodes anyway - I see that the proposed push instruction
format will not work eighter - I can't subreg the XFmode to TFmode.
Implementing pushes in a way as pops are handled in i386.md (i.e as parallels
w/o the pre_dec operands) can be way, but it is quite nasty too, sicne
we will have to teach generic code, such as combine_stack_adjustements
to discover these as push insns.
Honza
next reply other threads:[~2000-07-16 7:04 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2000-07-16 7:04 Jan Hubicka [this message]
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
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=20000716160420.A26370@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).