Hi All, I did a change proposed by Richard - unconditionally allocate from the heap.
Bootstrap and regression testing did not show any new failures. Is it OK for trunk? ChangeLog 2015-01-15 Yuri Rumyantsev <ysrum...@gmail.com> PR tree-optimization/64434 * cfgexpand.c (reorder_operands): New function. (expand_gimple_basic_block): Insert call of reorder_operands if optimized is true. gcc/testsuite/ChangeLog * gcc.dg/torture/pr64434.c: New test. 2015-01-14 17:07 GMT+03:00 Yuri Rumyantsev <ysrum...@gmail.com>: > Jakub, > > I did all changes requested by you. > > Here is updated patch. > > BTW I thought that gcc performs splitting of blocks with huge size. > > > 2015-01-14 16:33 GMT+03:00 Jakub Jelinek <ja...@redhat.com>: >> On Wed, Jan 14, 2015 at 04:28:42PM +0300, Yuri Rumyantsev wrote: >>> Hi All, >>> >>> I did all changes proposed by Richard and delete check on def in the >>> same block as Jakub proposed. >>> I also moved check on optimization to call site.. >>> >>> I also checked that bootstrap and regression testing did not show any >>> new failures. >>> >>> Is it OK for trunk? >> >> The | SSA_OP_VUSE is still in there, the testcase is still executable, >> still doesn't end with newline, and I really think you should replace >> lattice = XALLOCAVEC (unsigned int, n); >> with something like: >> if (n >= 100000) >> lattice = XNEWVEC (unsigned int, n); >> else >> lattice = XALLOCAVEC (unsigned int, n); >> ... >> if (n >= 100000) >> XDELETE (lattice); >> or similar. >> >> Jakub
patch2
Description: Binary data
