On Oct 20, 2024, Alexandre Oliva wrote:
> the x86 hits are newer, and
> the line numbers didn't help me find the errors, so I don't even know
> whether it's macros that we're talking about. These new warnings were
> encouraging, for they showed that the ifcombine incarnation of the patch
> cover
On Sat, Nov 2, 2024 at 12:20 PM Alexandre Oliva wrote:
>
>
> It became apparent that conditions could be combined that had deep SSA
> dependency trees, that might thus require moving lots of statements.
> Set a hard upper bound for now, hopefully to be replaced by a
> dynamically computed bound, b
It became apparent that conditions could be combined that had deep SSA
dependency trees, that might thus require moving lots of statements.
Set a hard upper bound for now, hopefully to be replaced by a
dynamically computed bound, based on probabilities and costs.
Also reset flow sensitive info a
On Fri, Oct 25, 2024 at 4:39 PM Alexandre Oliva wrote:
>
>
> In preparation to changes that may modify both inner and outer
> conditions in ifcombine, drop the redundant parameter result_inv, that
> is always identical to inner_inv.
OK.
>
> for gcc/ChangeLog
>
> * tree-ssa-ifcombine.cc
On Fri, Oct 25, 2024 at 4:39 PM Alexandre Oliva wrote:
>
>
> Rework ifcombine to support merging conditions from noncontiguous
> blocks. This depends on earlier preparation changes.
>
> The function that attempted to ifcombine a block with its immediate
> predecessor, tree_ssa_ifcombine_bb, now l
On Fri, Oct 25, 2024 at 4:39 PM Alexandre Oliva wrote:
>
>
> Prepare to handle noncontiguous ifcombine, introducing logic to modify
> the outer condition when needed. There are two cases worth
> mentioning:
>
> - when blocks are noncontiguous, we have to place the combined
> condition in the ou
On Fri, Oct 25, 2024 at 4:39 PM Alexandre Oliva wrote:
>
>
> Prepare for ifcombining noncontiguous blocks, adding (still unused)
> logic to the ifcombine profile updater to handle such cases.
>
>
> for gcc/ChangeLog
>
> * tree-ssa-ifcombine.cc (known_succ_p): New.
> (update_profil
On Fri, Oct 25, 2024 at 4:39 PM Alexandre Oliva wrote:
>
>
> Refactor ifcombine_ifandif, moving the common code from the various
> paths that apply the combined condition to a new function.
>
>
> for gcc/ChangeLog
>
> * tree-ssa-ifcombine.cc (ifcombine_replace_cond): Factor out
>
On Fri, Oct 25, 2024 at 4:39 PM Alexandre Oliva wrote:
>
>
> Disallowing vuses in blocks for ifcombine is too strict, and it
> prevents usefully moving fold_truth_andor into ifcombine. That
> tree-level folder has long ifcombined loads, absent other relevant
> side effects.
OK.
Richard.
>
> fo
The upcoming move of fold_truth_andor to ifcombine brings with it the
possibility of TRUTH_ANDIF cond exprs. Handle them by splitting the
cond so as to best use both BB insertion points, but only if they're
contiguous.
for gcc/ChangeLog
* tree-ssa-ifcombine.c (ifcombine_replace_cond)
Prepare to handle noncontiguous ifcombine, introducing logic to modify
the outer condition when needed. There are two cases worth
mentioning:
- when blocks are noncontiguous, we have to place the combined
condition in the outer block to avoid pessimizing carefully crafted
short-circuited te
Rework ifcombine to support merging conditions from noncontiguous
blocks. This depends on earlier preparation changes.
The function that attempted to ifcombine a block with its immediate
predecessor, tree_ssa_ifcombine_bb, now loops over dominating blocks
eligible for ifcombine, attempting to c
Refactor ifcombine_ifandif, moving the common code from the various
paths that apply the combined condition to a new function.
for gcc/ChangeLog
* tree-ssa-ifcombine.cc (ifcombine_replace_cond): Factor out
of...
(ifcombine_ifandif): ... this.
---
gcc/tree-ssa-ifcombin
Prepare for ifcombining noncontiguous blocks, adding (still unused)
logic to the ifcombine profile updater to handle such cases.
for gcc/ChangeLog
* tree-ssa-ifcombine.cc (known_succ_p): New.
(update_profile_after_ifcombine): Handle noncontiguous blocks.
---
gcc/tree-ssa-ifco
In preparation to changes that may modify both inner and outer
conditions in ifcombine, drop the redundant parameter result_inv, that
is always identical to inner_inv.
for gcc/ChangeLog
* tree-ssa-ifcombine.cc (ifcombine_ifandif): Drop redundant
result_inv parm. Adjust all ca
Disallowing vuses in blocks for ifcombine is too strict, and it
prevents usefully moving fold_truth_andor into ifcombine. That
tree-level folder has long ifcombined loads, absent other relevant
side effects.
for gcc/ChangeLog
* tree-ssa-ifcombine.c (bb_no_side_effects_p): Allow vuses
On Oct 22, 2024, Richard Biener wrote:
> On Mon, Oct 21, 2024 at 4:30 AM Alexandre Oliva wrote:
>>
>> On Oct 10, 2024, Richard Biener wrote:
>>
>> > As you special-case hard register uses, do we want to ever make
>> > hard-register
>> > uses or defs unconditional? I'll note that on GIMPLE h
I've just posted 7 patches related with the implementation of
noncontiguous ifcombine. They've been regstrapped together on
x86_64-linux-gnu, and each patch has been tested to build on top of the
previous on.
Patches #1, #2 and #3 are preparatory patches that stand on their own.
Patches #4, #5 a
On Mon, Oct 21, 2024 at 4:30 AM Alexandre Oliva wrote:
>
> On Oct 10, 2024, Richard Biener wrote:
>
> > Thanks for working on this. There's #if 0 portions in the patch - did you
> > send the correct version?
>
> 'fraid so. Sorry, I'd forgotten about that bit. Long story (not so)
> short, this
On Oct 10, 2024, Richard Biener wrote:
> Thanks for working on this. There's #if 0 portions in the patch - did you
> send the correct version?
'fraid so. Sorry, I'd forgotten about that bit. Long story (not so)
short, this patch is a bit of a frankenstein monster: there's a large
portion from
On Thu, Sep 26, 2024 at 10:49 AM Alexandre Oliva wrote:
>
>
> This patch introduces various improvements to the logic that merges
> field compares, moving it into ifcombine.
>
> Before the patch, we could merge:
>
> (a.x1 EQNE b.x1) ANDOR (a.y1 EQNE b.y1)
>
> into something like:
>
> (((type
This patch introduces various improvements to the logic that merges
field compares, moving it into ifcombine.
Before the patch, we could merge:
(a.x1 EQNE b.x1) ANDOR (a.y1 EQNE b.y1)
into something like:
(((type *)&a)[Na] & MASK) EQNE (((type *)&b)[Nb] & MASK)
if both of A's fields li
22 matches
Mail list logo
