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

[Christian Bruel <chrbr at free dot fr>]

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 
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,

Christian

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?
>
> Uros.