------- Comment #12 from amacleod at redhat dot com 2007-11-07 13:52 ------- Subject: Re: [4.3 Regression] ICE in ssa_operand_alloc, at tree-ssa-operands.c:487 with -O3
rguenther at suse dot de wrote: > ------- Comment #11 from rguenther at suse dot de 2007-11-06 21:36 ------- > Subject: Re: [4.3 Regression] ICE in > ssa_operand_alloc, at tree-ssa-operands.c:487 with -O3 > > On Tue, 6 Nov 2007, amacleod at redhat dot com wrote: > > >> Partitioning doesn't really seem to be the root problem. >> > > But partitioning should exactly help avoiding this: > There is also an issue with partitioning, but it would then hide what I think is an important issue. Partitioning's problem is that it counts the number of items in the alias set and just uses that. There is only one entry for an entire SFT list, so it misses the other 819 in this particular list. The difficulty is determining how many of those SFTs are actually going to be relevant. Ideally, partitioning would share code with VOP processing so it can see exactly how many VOPs would be generated by each MEM. > >> looking at testcase-min.i: >> There are about 820 SFTs associated with the giant structure, and we decide >> that they *all* can be affected by the memory access and try to issue VOPS >> for >> them. >> > > 820 virtual operands should not happen because we have partitioning. > this is true, but it is also true we should not be generating 820 vops for this particular stmt. > >> An int is loaded via MEM[base: Hoopster_ptr_17, offset: 3552]. >> In get_tmr_operands(), we always call add_virtual_operands() with an offset >> of >> 0 and a size of -1. This seems wrong. we should be able to use the size of >> the >> load and offset information to figure out the right SFT(s) to add. Instead, >> because the size is -1, we simply include all of them. >> >> Is this offset of 0 and size of -1 to paper over something else? I understand >> there might be issues trying to get the right offset and base calculations >> under some conditions... >> > > I think TMR had not precise enough alias information that we did want to > play safe here. In some cases (only constant offsets and strides) we > might be able to optimize this. > I dunno. The MEM has a very clear base, and a very clear offset, and a very clear size, it certainly LOOKS like it should be able to figure it out. The code in get_tmr_operands makes no attempt whatsoever to figure it out. It hard codes an offset of 0 and a size of -1 to add_virtual_operands, which is then forced to add all 820 virtual ops. Perhaps there are deeper issues, but ultimately, it would be nice to do that right thing here and try to pick the right SFT(s) if possible. That said, both problems do need to be addressed. Andrew -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31976
