https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58416
--- Comment #19 from Martin Jambor <jamborm at gcc dot gnu.org> --- (In reply to Richard Biener from comment #18) > (In reply to Martin Jambor from comment #15) > > Created attachment 58724 [details] > > simple (wip) fix > > > > I'm wondering whether just simply something like this would not be enough. > > I have looked at total scalarization and we will not replace a type found in > > the IL with another one there. Similarly, only propagation through > > assignments fiddles with existing types (when they are not aggregate) only > > when propagating from RHS to LHS and not the other way round. > > > > If we want to be more aggressive, we can add a flag when the new predicate > > fails but there is a good bitwise_type_for_mode and then when the flag is > > set, use that type instead in analyze_access_subtree. > > > > Note that so far I have only tested the attached patch with > > make -k check-gcc RUNTESTFLAGS="tree-ssa.exp=*sra*.c" > > make -k check-g++ RUNTESTFLAGS="dg.exp=*sra*.c" > > make -k check-gcc RUNTESTFLAGS="dg.exp=*sra*.c" > > > > I'll have a look at full test results tomorrow morning. > > I think it should be OK to fix the wrong-code issue in this bug but it > prevents scalarization completely, likely at least failing > gcc.dg/tree-ssa/sra-6.c I did check that even yesterday night and it passes but g++.dg/vect/pr64410.cc and gcc.dg/tree-ssa/pr32964.c fail. I'm investigating. > > Note the name of the predicate should probably reflect the problem, > like can_use_type_as_storage_for (tree storage_type, tree value_type) > or so. Yes, I'm aware it is less than ideal so far. I was not sure what the final version would be like. THe version from yesterday unnecessarily pessimizes cases where the "other" type is a structure containing just the float or one element array, or a combination, that at least should be addresses. > > With my patch I trieds to instead use a bit-pattern preserving load > similar as what we do with non-mode precision integer prevailing types. > > Note I plan to add a new target hook to identify problematic FP modes. That would be super-helpful.
