Ian Lance Taylor wrote:
Are you emitting CLI directly from GIMPLE?
Yes, we emit gimple right before GIMPLE is transformed into RTL so our code doesn't go through the RTL-only optimizations
It may help to look at store_bit_field and extract_bit_field so see how this sort of thing is handled when expanding trees to RTL.
I've looked a bit into them and we currently deal with bit-fields roughly that way when we emit CLI code. Our current solution works but emits poor code as it generates a lot of temporaries which are not cleaned up later. I was trying to move some of our expansions before the tree-ssa optimizations hoping to simplify the emission phase and to obtain better code.
I don't recommend adding artificial fields to the struct. If you need them in CLI, then add them at CLI generation time. If you can get away with direct memory references, then do that.
I see. I don't need the extra fields inside the struct, in fact the CLI emission simply ignores them they would be needed only as 'container' fields referenced by the new COMPONENT_REF statements I inject to replace the bit-field ones. I can certainly get away with indirect references instead. In that case do I have to set TREE_ADDRESSABLE() on the enclosing type? BTW I'm currently doing these transformations right before the control-flow graph is built. Thank you very much for your help.
Gabriele
