http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58253
--- Comment #5 from rguenther at suse dot de <rguenther at suse dot de> --- On Fri, 29 Nov 2013, jamborm at gcc dot gnu.org wrote: > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58253 > > --- Comment #3 from Martin Jambor <jamborm at gcc dot gnu.org> --- > (In reply to rguent...@suse.de from comment #2) > > Isn't it easier to avoid building a type with different alignment > > in the first place? Or do this adjustment in SRA where the bug > > happens? It seems that when SRA representatives ->type is unaligned > > that this means, for by value passing, the value is accessed unaligned > > in the caller only. Thus turn_representatives_into_adjustments > > should go back to naturally aligned ->type for !by_ref params. > > > > That's what the first version of my patch did :-) The problem with it > is that the alignment of the type in adjustment is how > ipa_modify_call_arguments figures out it needs to build unaligned > loads in the caller and so those types need to stay unaligned and only > ipa_modify_formal_parameters needs to be taught to ignore that. ;) > BTW, now I wonder whether it would make more sense to check for > is_gimple_reg_type instead of non-BLKmode-ness with perhaps the latter > asserted. Arguably, the actual arguments are (formally well aligned) > SSA names because their type is a gimple register. Well - how an actual PARM_DECL passed by value ends up being aligned is up to the target, independent of whether it will be an SSA register or an aggregate. But we certainly should make the life of the targets easier by using natural alignment when inventing new pass-by-value PARM_DECLs. Richard.
