This is the mail archive of the 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]
Other format: [Raw text]

Re: [PATCH] support to flip modes in sh mode-switching

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 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 participate.

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.

Best Regards,


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 fits. For

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?


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