This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [vta, vta4.4] merged with trunk and 4.4 @149247, updated VTA patchset
On Jul 7, 2009, Richard Guenther <richard.guenther@gmail.com> wrote:
> On Tue, Jul 7, 2009 at 11:10 AM, Alexandre Oliva<aoliva@redhat.com> wrote:
>> On Jul Â6, 2009, Richard Guenther <richard.guenther@gmail.com> wrote:
>>> ...
>>> + Â Â Â Â Â Â do
>>> + Â Â Â Â Â Â Â {
>>> + Â Â Â Â Â Â Â Â gsi_prev (&si);
>>> + Â Â Â Â Â Â Â Â if (gsi_end_p (si))
>>> + Â Â Â Â Â Â Â Â Â break;
>>> + Â Â Â Â Â Â Â }
>>> + Â Â Â Â Â Â while (gsi_stmt (si) != stmt);
>>
>>> you are linearly walking stmts. ÂIf you rely on dominators then
>>> why not rely on stmt uids being present and correct?
>>
>> Because uids didn't exist back when I wrote this code, and I didn't
>> realize they had been added.
>>
>> I don't see that there's any way to test whether they're available when
>> I need them, and I don't see that it is available in the passes that
>> call adjust_debug_stmts_for_var_def_move or adjust_debug_stmts_for_move.
>> Should I add code for these passes compute uids, should this function
>> compute uids on the fly as needed (we'd need some means to test whether
>> uids are computed and sufficiently up to date, ideally on a per-block
>> basis), or do you have something else in mind?
> I'm not sure. I would have tried to minimize use of the function more
> (to the extent of removing it - heh). What bad will happen if
> you just always punt if the BBs are the same? I suspect most
> code-motion optimizations move/insert across BB boundaries
> anyway...
FWIW, adding an inform() in the beginning of the block containing the
loop above, I get 26367 hits during stage3+libs, and another 2700+ hits
in gcc/testsuite/*[^0-9]/*.log
--
Alexandre Oliva, freedom fighter http://FSFLA.org/~lxoliva/
You must be the change you wish to see in the world. -- Gandhi
Be Free! -- http://FSFLA.org/ FSF Latin America board member
Free Software Evangelist Red Hat Brazil Compiler Engineer