LFTR is not a safe optimization and never will be Sun On Tue, May 24, 2011 at 8:53 AM, Ye, Mei <mei...@amd.com> wrote: > > > My earlier check-in r3502 forces loop end-test comparison to be "unsigned" > in the Linear Function Test Replacement (LFTR) phase. This fixes an > overflow problem when memory address crosses the boundary of 0x80000000 in > 32-bit architectures. The fix exposes another bug in Linear Function Test > Replacement, which is explained below using the following pseudo-codes, > where "sym7" is the original loop index, "sym11" is the memory address that > replaces the original loop index as the induction variable, and "end" is the > loop upper bound. If the value of the memory address is very closed to > 0xffffffff, adding a positive constant can overflow and produces a small > positive result for "sym11v5", which then causes "sym11v5 <= end" to be > evaluated as "TRUE", and the loop is mistakenly executed many more times > than it should. This leads to seg faults. > > > > sym7v3 = const1 > > sym11v3 = sym7v3 + sym3 > > > > LABEL: > > sym11v4 = phi(sym11v3, sym11v5) > > *sym11v4 = ... > > sym11v5 = sym11v4 + const2 > > if (sym11v5 <= end) > > goto LABEL > > > > To fix this bug, we transform the above code into the following. > > > > sym7v3 = const1 > > sym11v3 = const1 - const2 + sym3 // The result of 'const1 - const2' should > use signed type. > > LABEL: > > sym11v4 = phi(sym11v3, sym11v5) > > sym11v5 = sym11v4 + const2 > > *sym11v5 = ... > > if (sym11v5 <= end - const2) > > goto LABEL > > > > > > This transformation uses pre-increment instead of post-increment for the > induction variable update and replaces the use of "sym11v4" with > "sym11v5". > > > > My implementation replaces CR operands associated with "sym11v4" without > rehashing since none of these expressions appear outside of the loop. It is > also impractical to rehash these expressions at this point since doing so > will burn compilation time to find each occurrence from all the worklsts. I > also avoid the situations that the transformation will create new > expressions having CSE occurrences outside of the loop. This is to avoid > changing CODEREPs unintentionally. > > > > Although this work still will not make LFTR 100% safe, but it should cover a > vast majority. > > ------------------------------------------------------------------------------ > vRanger cuts backup time in half-while increasing security. > With the market-leading solution for virtual backup and recovery, > you get blazing-fast, flexible, and affordable data protection. > Download your free trial now. > http://p.sf.net/sfu/quest-d2dcopy1 > _______________________________________________ > Open64-devel mailing list > Open64-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/open64-devel > >
------------------------------------------------------------------------------ vRanger cuts backup time in half-while increasing security. With the market-leading solution for virtual backup and recovery, you get blazing-fast, flexible, and affordable data protection. Download your free trial now. http://p.sf.net/sfu/quest-d2dcopy1 _______________________________________________ Open64-devel mailing list Open64-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/open64-devel
