On Thu, 23 Apr 2020, Richard Biener via Gcc-patches wrote: > I think at least one step would be uncontroversical(?), namely moving > the RTL expansion "magic" > up to a GIMPLE pass. Where the "magic" would be to turn > GIMPLE stmts not directly expandable via an existing optab into > GIMPLE that can be trivially expanded. That includes eventually
I suspect some such pieces should actually happen before some GIMPLE optimizations are done, rather than as the last pass before expansion - though then you need to make sure subsequent GIMPLE passes don't reintroduce the operations you've lowered. E.g. the special handling of arithmetic on bit-field types in expand is a good candidate for being a lowering step (lowering to operations on integer widths actually supported by the machine / that correspond to known machine modes) somewhere in GIMPLE processing (and you don't want to subsequently narrow back to operations on those widths that don't exist in hardware). Note in that regard that there is a proposal for C2x to support integer types with a specified number of bits more generally than just as bit-fields. > That said, I actually agree with that. It's just that I hope we can > make some of the knowledge just represented on the RTL side > available on the GIMPLE side. The more complicated parts, > like calling conventions, that is. On the other hand, there is some knowledge like that which should move out of the front ends, into a GIMPLE lowering step (front ends should not be calling targetm.calls.promote_prototypes and changing their internal representation accordingly, that information should be handled later in the compiler, probably on GIMPLE). -- Joseph S. Myers jos...@codesourcery.com
