On Tue, Mar 12, 2013 at 8:18 AM, Wei Mi wrote: > For the motivational case, I need insn splitting to get the cost > right. insn splitting is not very intrusive. All I need is to call > split_insns func.
It may not look very intrusive, but there's a lot happening in the back ground. You're creating a lot of new RTL, and then just throw it away again. You fake the compiler into thinking you're much deeper in the pipeline than you really are. You're assuming there are no side-effects other than that some insn gets split, but there are back ends where splitters may have side-effects. Even though I've asked twice now, you still have not explained this motivational case, except to say that there is one. *What* are you trying to do, *what* is not happening without the splits, and *what* happens if you split. Only if you explain that in a lot more detail than "I have a motivational case" then we can look into what is a proper solution. The problem with some of the splitters is that they exist to break up RTL from 'expand' to initially keep some pattern together to allow the code transformation passes to handle the pattern as one instruction. This made sense when RTL was the only intermediate representation and splitting too early would inhibit some optimizations. But I would expect most (if not all) such cases to be less relevant because of the GIMPLE middle-end work. The only splitters you can trigger are the pre-reload splitters (all the reload_completed conditions obviously can't trigger if you're splitting from fwprop). Perhaps those splitters can/should run earlier, or be made obsolete by expanding directly to the post-splitting insns. Unfortunately, it's not possible to tell for your case, because you haven't explained it yet... > So how about keep split_insns and remove peephole in the cost estimation func? I'd strongly oppose this. I do not believe this is necessary, and I think it's conceptually wrong. >> What happens if you propagate into an insn that uses the same register >> twice? Will the DU chains still be valid (I don't think that's >> guaranteed)? > > I think the DU chains still be valid. If propagate into the insn that > uses the same register twice, the two uses will be replaced when the > first use is seen (propagate_rtx_1 will propagate all the occurrances > of the same reg in the use insn). When the second use is seen, the > df_use and use insn in its insn_info are still available. > forward_propagate_into will early return after check reg_mentioned_p > (DF_REF_REG (use), parent) and find out no reg is used any more. With reg_mentioned_p you cannot verify that the DF_REF_LOC of USE is still valid. In any case, returning to the RD problem for DU/UD chains is probably a good idea, now that RD is not such a hog anymore. In effect fwprop.c would return to what it looked like before the patch of r149010. As a way forward on all of this, I'd suggest the following steps, each with a separate patch: 1. replace the MD problem with RD again, and build full DU/UD chains. 2. post all the recog changes separately, with minimum impact on the parts of the compiler you don't really change. (For apply_change_group you could even choose to overload it, or use a NUM argument with a default value -- not sure if default argument values are OK for GCC tho'.) 3. implement propagation into multiple USEs, but without the splitting and peepholing. 4. see about fixing the back end to either split earlier or expand to the desired patterns directly. Ciao! Steven
