On Fri, 2005-04-08 at 12:52, Jeffrey A Law wrote: > In the interest of brevity, I'm just going to point out the > problematical store from the .ifcvt dump: > > > # x_16 = V_MAY_DEF <x_21>; > # SFT.3_20 = V_MAY_DEF <SFT.3_15>; > *D.1470_8 = D.1472_11; > > Which gets vectorized and appears like this in the .vect dump: > > > > # x_16 = V_MAY_DEF <x_21>; > # SFT.3_20 = V_MAY_DEF <SFT.3_15>; > *vect_px.17_36 = vect_var_.10_29; > > Which looks perfectly fine. Unfortunately, there is a huge problem. > If the operands for that statement are rebuilt, then we are going to > lose the assignment to SFT.3_20. <...>
> This is safe if and only if the the operand scanning code will compute > the same V_MAY_DEFS for the original scalar statement and the new > vectorized statement. ie, *D.1470 must have the same aliasing > properties as *vect_px.17. > > This works in the mainline because nothing ever causes a rescan of > the statement's operands. However, with some pending changes I've got > to the jump threader, IVopts will later want to change *vect_px.17_36 > in the vectorized statement, which causes a rescan of the operands. > > When we rescan the operands, we get a different set of V_MAY_DEFS, > specifically we lose the V_MAY_DEF for SFT.3_20. Which results in > uses of SFT.3_20 later, but SFT.3_20 is never defined What are these uses? If they are references to things that aliased *D.1470_8, we should eliminate the VUSE/MAYDEF, shouldnt we? I presume they arent relevant any more if vec_px.17 isnt in the same alias set. And if they are relevant, then we need to find out what the new variable is, and change all the uses to the new one Andrew
