Re: [PATCH] Fix one part of PR42108

["H.J. Lu" <hjl.tools@gmail.com>]

On Sat, Dec 19, 2009 at 10:50 AM, H.J. Lu <hjl.tools@gmail.com> wrote:
> On Fri, Dec 18, 2009 at 3:29 PM, Richard Guenther <rguenther@suse.de> wrote:
>>
>> This fixes one part of PR42108, the missed discovery of a full
>> redundant load.  The issue is that the SSA SCC value-numberer
>> does not visit loads and stores in a defined order.  The (or rather
>> one) fix is to properly canonicalize the virtual operand SSA names
>> we record in the expression hash tables.  The proper canonical
>> virtual operand is the def of the first dominating may-definition
>> (or a PHI node vdef, but we can as well choose a non-may-definition
>> without loss of precision and generality).
>>
>> The patch possibly slows down SCCVN a bit for examples like
>>
>>   # .MEM_2 = VDEF <.MEM_1(D)>
>>   may-def
>>  ....
>>   # VUSE <.MEM_120>
>>   ... = X;
>>   # VUSE <.MEM_120>
>>   ... = X;
>>
>> where discovering the redundant load of X needs to canonicalize
>> their VUSE SSA name twice (previously we entered the expression
>> into the hashtable with .MEM_120 so it would be found immediately).
>> Now if we had
>>
>>   # VUSE <.MEM_60>
>>   ... = X;
>>
>> inbetween the may-def and the other loads we previously discovered
>> the full redundancy only if we first visited the load with .MEM_60
>> and only after that the loads with .MEM_120.  But nothing guarantees
>> this - this is the case the patch fixes.  There are about 0.5%
>> more redundant loads discovered in tramp3d with this patch.
>>
>> This is a regression of the alias-improvements branch merge as
>> previously we had different virtual operands and thus in more
>> cases the canonical vuses were automagically chosen.
>>
>> Bootstrapped and tested on x86_64-unknown-linux-gnu.  I have patched
>> one of our SPEC / C++ testers for more testing coverage.
>>
>
> This may have caused:
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42435
>

This also caused:

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49279


-- 
H.J.