On Wed, Jun 12, 2013 at 6:04 PM, Jeff Law wrote:
>
> On 06/07/13 03:14, Richard Biener wrote:
>
>>> +/* Given SSA_NAMEs NAME1 and NAME2, return true if they are candidates
>>> for
>>> + coalescing together, false otherwise.
>>> +
>>> + This must stay consistent with the code in tree-ssa-live.c
On 06/07/13 03:14, Richard Biener wrote:
+/* Given SSA_NAMEs NAME1 and NAME2, return true if they are candidates for
+ coalescing together, false otherwise.
+
+ This must stay consistent with the code in tree-ssa-live.c which
+ sets up base values in the var map. */
+
+bool
+gimple_can_c
On 06/07/13 03:14, Richard Biener wrote:
+/* Given SSA_NAMEs NAME1 and NAME2, return true if they are candidates for
+ coalescing together, false otherwise.
+
+ This must stay consistent with the code in tree-ssa-live.c which
+ sets up base values in the var map. */
+
+bool
+gimple_can_
On 06/07/13 02:30, Steven Bosscher wrote:
On Fri, Jun 7, 2013 at 8:07 AM, Jeff Law wrote:
Rather than using strict pointer equality, we can do better by looking at
TYPE_CANONICAL when it's available. Thus objects of the following two types
(T1 & T2) become candidates for coalescing if they are
On Fri, Jun 7, 2013 at 8:07 AM, Jeff Law wrote:
>
> I stumbled over this while looking at regressions triggered when moving
> certain branch-cost driven transformations from fold-const.c to a later
> point in the pipeline.
>
> The coalescing we do as part of the out-of-ssa process restricts itself
On Fri, Jun 7, 2013 at 8:07 AM, Jeff Law wrote:
> Rather than using strict pointer equality, we can do better by looking at
> TYPE_CANONICAL when it's available. Thus objects of the following two types
> (T1 & T2) become candidates for coalescing if they are tied together by a
> copy or PHI node.
