This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

pre_inc/pre_dec/PUSH_ROUNDING inconsistency


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]