This is the mail archive of the
mailing list for the GCC project.
Re: [PATCH] support to flip modes in sh mode-switching
- From: Christian Bruel <chrbr at free dot fr>
- To: Uros Bizjak <ubizjak at gmail dot com>
- Cc: Christian BRUEL <christian dot bruel at st dot com>, 'GCC Patches' <gcc-patches at gcc dot gnu dot org>, amylaar at gcc dot gnu dot org
- Date: Sat, 23 Dec 2006 13:58:24 +0100
- Subject: Re: [PATCH] support to flip modes in sh mode-switching
- References: <firstname.lastname@example.org> <458D1413.email@example.com>
I had a brief look at the x87 mode switching, (I wanted to understand
why I never get the gcc_assert in 'merge_modes'), scared by Joern's mail
;-). From what I've seen modes are handled thur different identities.
When it gets to the mode-switching pass there are 2 possible values for
each entity (see ix86_mode_needed): i387_cw_any (that is no_mode) or
i387_cw_[trunc,ceil, ...] depending of the entity. So I never asserted
because it was not possible to have avin set in the same time for
different modes (in different entities).
So indeed, the mode _flipping_ patch could help flipping it. But I think
that attributes in I386.md would need to be modified, because a "flip"
must be done between 2 exclusives modes. I don't know enough about x87
to go further but if someone wants to try I would be very happy to
Coming back to my patch, when thinking over it I have two modifications:
1) renaming 'merge_mode', too confusing, to 'set_flip_status'
2) I was too restritive with the assertion, only considering the sh flip
mode that can only be between double or float. If an entity (no cases in
gcc yet) has more than 2 values it should not assert, and the or should
be modified to a xor and force a no_flip status.
With my approach, the rule is: inside an entity, we need 2 exclusives
modes (and only 2) plus the "no_mode" to enable flipping. All others
cases will generate a setting. Since x87 modes have one mode/entity the
flip will not work as attributes and MODE macros are on today.
Uros Bizjak wrote:
Christian BRUEL wrote:
Thanks for the pointers. From what I see from #19161, the mode-switching
pass would need to be connected to the register class selection ? That's
more that what it does but that would be interesting to see how it
No, for SH, you don't have to select different register classes. This is
specific to x87->mmx switch, as no values should live in any of
registers during the switch. This was achieved by modelling emms to
"use" all x87 registers (and similar for efpu insn and MMX register),
and this info was propagated over edges to previous blocks. In some
cases involving two or more incoming edges, both register sets can
become "used" on a BB entry, and no further insn could use neither MMX
nor x87 registers.
I was hoping that by your mode-flipping approach, exclusivity of modes
can be obtained. This is IMO the same problem as with SH-4a mode
flipping patch. Consider the case, where one incoming edge is set to
DFmode, while the other is set to SFmode, and somewhere in the BB your
insn wants i.e. DFmode. With mode-setting, the situation is clear; you
force mode to DFmode before insn. But for mode-flipping approach, do you
want to flip mode or not?