On Thu, Sep 15, 2016 at 10:27:56AM -0600, Jeff Law wrote: > On 09/15/2016 10:10 AM, Trevor Saunders wrote: > > On Thu, Sep 15, 2016 at 12:52:59PM +0200, Bernd Schmidt wrote: > > > On 09/14/2016 09:21 PM, tbsaunde+...@tbsaunde.org wrote: > > > > > > > Basically $subject. First change variable's type to rtx_insn * where > > > > possible. > > > > Then change the functions and fixup callers where it is still necessary > > > > to > > > > cast. > > > > > > #2, #4 and #8 look good and can be applied if they work independently of > > > the > > > others. > > > > at most #2 should depend on #1 so it should be fine and I can check on > > the others. > > > > > Less certain about some of the others which introduce additional casts. > > > > yeah, its somewhat unfortunate, though one way or another we will need > > to add casts I think the question is just how many we will accept and > > where. > In my mind the casts represent the "bounds" of how far we've taken this > work. They occur at the boundaries where we haven't converted something > from an "rtx" to an "rtx_insn *" and allow us to do the work piecemeal > rather than all-at-once. > > What I don't have a sense of is when we'll be able to push rtx_insn * far > enough that we're able to start removing casts.
Well, this series does remove a few, though I'm sure it is a net addition. > And that might be a good way to prioritize the next batch of work. Pick a > cast, remove it and deal with the fallout. :-) yeah, that's more or less what I did here. each of the next_X_insn methods took a rtx and cast it to rtx_insn *, so I changed it to take a rtx_insn * and dropped the cast. Then I fixed up the fallout and moved the conversion of variable types to the beginning of the series since it is less objectionable. > > > > > Maybe LABEL_REF_LABEL needs converting first, and reorg.c has a few > > > variables that might have to be made rtx_insn * in patch #7 to avoid > > > casts. > > > > LABEL_REF_LABEL might be doable, its a good idea I'll look into. The > > reorg.c stuff around target_label is rather complicated unfortunately. > > In the end I of course agree the variables should be rtx_insn *. > > However currently things are assigned to that variable that are not > > insns. So we need to break the variable up, but its involved in a lot > > of code I don't think I know well enough to really refactor. For > > example it looks like target_label can hold a value between iterations > > of the loop, I suspect that would be a bug, but I'm not really sure. > I can probably help with reorg. Hell, you might even be referring to my > code! heh, that'd be useful. Though I'm not really sure how important it is to clean up code specific to targets with delay slots. Trev > jeff
