On 26 November 2013 16:59, Reid Kleckner <rnk at google.com> wrote:> I'd support disabling tail merging of calls at -O1. The other CFG > simplification doesn't seem like that big of a deal though for general > debugging, though. >So, do we have two ways of running SimplifyCFG? One for O1 and one for O2+, and selectively disabling parts of it? --renato -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20131126/7aaf6025/attachment.html>
Reid,
by the other CFG simplification, do you mean this case in
http://llvm-reviews.chandlerc.com/D2214?
1: if (x < 0)
2: if (y < 0)
3: do_something();
Yes, this is only bad for MSan (and probably for sampling-based PGO,
but that's a whole different story). But the current version of D2214
disables this optimization at SimplifyUncondBranch() point, which also
covers HoistThenElseCodeToIf(). And that one is exactly as bad as tail
merging of calls:
void f(int x) {
if (x == 1) {
g();
g1();
} else {
g();
g2();
}
}
Calls to g() are hoisted out of if/else blocks.
Also note that tail merging of calls happens in CodeGen, not in SimplifyCFG.
On Tue, Nov 26, 2013 at 9:45 PM, Renato Golin <renato.golin at linaro.org>
wrote:> On 26 November 2013 16:59, Reid Kleckner <rnk at google.com> wrote:
>>
>> I'd support disabling tail merging of calls at -O1. The other CFG
>> simplification doesn't seem like that big of a deal though for
general
>> debugging, though.
>
>
> So, do we have two ways of running SimplifyCFG? One for O1 and one for O2+,
> and selectively disabling parts of it?
>
> --renato
On 27 November 2013 08:43, Evgeniy Stepanov <eugeni.stepanov at gmail.com>wrote:> Also note that tail merging of calls happens in CodeGen, not in > SimplifyCFG. >Hi Evgenly, What we need is the general information that we want to avoid too much code motion, from choosing the passes, to choosing steps on the passes, to lowering code differently. On the front-end layer, It's as simple as dealing -O levels. On the middle-end, we could have front-ends to set a flag "debug-illusion" on each individual pass, so that they could use this information to take decisions locally, independent of the -O level (which they don't have access to). This flag should only be set if the user requests -g and the optimization level is not greater than 1. On the back-end, I think the only place global enough that the front-end has access to is the Target description, which could have a similar flag to avoid folding too much during codegen. cheers, --renato -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20131127/89668558/attachment.html>