On Mon, Jul 13, 2015 at 8:29 AM, Michael Matz <m...@suse.de> wrote: > Hi, > > On Mon, 13 Jul 2015, Richard Biener wrote: > >> On Fri, Jul 10, 2015 at 5:46 PM, Jim Wilson <jim.wil...@linaro.org> wrote: >> > On Tue, Jul 7, 2015 at 2:35 PM, Richard Biener >> > <richard.guent...@gmail.com> wrote: >> >> On July 7, 2015 6:29:21 PM GMT+02:00, Jim Wilson <jim.wil...@linaro.org> >> >> wrote: >> >>>signed sub-word locals. Thus to detect the need for a conversion, you >> >>>have to have the decls, and we don't have them here. There is also >> >> >> >> It probably is. The decks for the parameter based SSA names are >> >> available, for the PHI destination there might be no decl. >> > >> > I tried looking again, and found the decls. I'm able to get correct >> > code for my testcase with the attached patch to force the conversion. >> > It is rather inelegant, but I think I can cache the values I need to >> > make this simpler and cleaner. I still don't have decls from >> > insert_part_to_rtx_on_edge and insert_rtx_to_part_on_edge, but it >> > looks like those are for breaking cycles, and hence might not need >> > conversions. >> >> Yes, that looks like a defect. CCing Micha who wrote this code > > I think it's a backend bug that parameters and locals are extended > differently. The code in tree-outof-ssa was written with the assumption > that the modes of RTL objects might be different (larger) than the tree > types suggest, but that they be _consistent_, i.e. that the particular > extension depends on only the types, not on the tree-type of the decl. > > I think the above assumption does make sense because it's also a > fundamental assumption in the whole gimple pipeline, types matter, not the > objects (or better, we slowly but surely work towards this). Hence such > mismatches should either not exist (changing the backend), or should be > exposed explicitely during gimplification already. The latter is a large > change, though. > > I think dealing with this situation in outof-ssa is a hack and I don't > like it. It would extend the ugliness of different modes for same types > even more, and that's something we should (gradually) move away from. >
Different parts of GCC have their own ideas how parameters should be promoted, which leads to subtle bugs like PR 64037. -- H.J.
