On Fri, May 29, 2015 at 11:14:46PM -0600, Jeff Law wrote: > On 05/29/2015 11:39 AM, Richard Sandiford wrote: > >One of the main early aims of the rtl refactoring is to finally separate > >instructions (rtx_insns) from other rtxes. I thought it would help if the > >compiler could warn about cases where a function returns rtx when it > >could return rtx_insn*, or where a variable has type rtx but could have > >type rtx_insn*. > > > >This patch tries to implement something along those lines. There are two > >warning options, one for function returns and one for variables. There are > >obviously many good reasons why a functon or variable might have a more > >general > >type than it might appear to need, so the options certainly aren't -Wall or > >-Wextra material. But it might be worth having them as stage 2 and 3 > >warnings. > I can't speak to the implementation as it hits the C++ front-end where my > knowledge approaches zero. But I can say that I really like what you're > trying to do here. I can easily see how it'd be useful for GCC.
Yeah, I did a bit of this manually a while ago, but automating things is good. It would also be useful to have something for arguments, but I guess that's harder and requires LTO, or at least some post processing. It would also be useful and also much harder to be able to automatically rewrite as well as detect these cases. > The big question in my mind is how useful would this be on other codebases > -- I have a hard time believing that GCC is the only codebase which has > these problems. I'm tempted to agree. I was going to say that I couldn't think of another example off the top of my head, but actually I think there are some things I could use it for or at least I'd give it a try for. The other more generic approach is to make it easier to write plugins to do this sort of thing. I've been pondering writing a checker plugin for gcc's code for a little while but haven't started on anything yet. Trev
