On Sep 28, 2020, Richard Biener <richard.guent...@gmail.com> wrote: > On Fri, Sep 25, 2020 at 3:39 PM Alexandre Oliva <ol...@adacore.com> wrote:
>> This patch introduces various improvements to the logic that merges >> field compares. > Sorry for throwing a wrench in here but doing this kind of transform > during GENERIC folding is considered a bad thing. Ugh. Even tree-ifcombine itself relies on tree folding logic to perform this and various similar sorts of optimizations. Is the issue just that we don't want to perform this kind of transformation while still in GENERIC, or that the logic must not even be there? I ask because it wouldn't be too hard to disable unwanted cases of folding while in GENERIC, and extending it to follow SSA defs so that ifcombine would those optimizations back at an acceptable spot. Please help me understand what it is that makes this change as it is undesirable, so that I can figure out how to do it in an acceptable way, and justify the additional time and effort it will take. I *think* ifcombine could even be extended so as to reuse the separate-test logic I put in, by looking for non-immediate dominating outer conditions for the inner condition. A further modified version of fold_truth_andor_1 could then be used to combine the separate tests. As for reassoc... It doesn't seem a good fit at all for reassociating short-circuiting boolean operations, that normally get translated as multiple basic blocks. -- Alexandre Oliva, happy hacker https://FSFLA.org/blogs/lxo/ Free Software Activist GNU Toolchain Engineer
