[RFA][PR tree-optimization/72785] Avoid duplicating blocks with b_c_p or b_o_s calls.

Jakub Jelinek jakub@redhat.com
Mon Oct 24 08:06:00 GMT 2016


On Mon, Oct 24, 2016 at 09:55:47AM +0200, Richard Biener wrote:
> Hum.  This means we no longer can for example apply loop versioning or
> peeling to loops containing any of both calls.  I've not yet traced down whether
> we can still inline functions containing such calls.

I agree gimple_can_duplicate_bb_p is too strong for this.

> That said, we _can_ duplicate blocks with such calls and I don't think
> that for b_c_p we guarantee anything about it (inlines into two different
> functions may produce true in one case and false in another).  Your
> testcase may show an interesting "odd" case but I don't think it's
> any different that what we regularly see or _want_ to see.
> 
> Same for b_o_s of course.
> 
> So I think the bug is no bug.

The problem is that it breaks something fairly common.  The linux kernel
has:
#define ilog2(n)                                \
(                                               \
        __builtin_constant_p(n) ? (             \
                (n) < 1 ? ____ilog2_NaN() :     \
                (n) & (1ULL << 63) ? 63 :       \
                (n) & (1ULL << 62) ? 62 :       \
...
                (n) & (1ULL <<  4) ?  4 :       \
                (n) & (1ULL <<  3) ?  3 :       \
                (n) & (1ULL <<  2) ?  2 :       \
                (n) & (1ULL <<  1) ?  1 :       \
                (n) & (1ULL <<  0) ?  0 :       \
                ____ilog2_NaN()                 \
                                   ) :          \
        (sizeof(n) <= 4) ?                      \
        __ilog2_u32(n) :                        \
        __ilog2_u64(n)                          \
 )

and the assumption that in the b_c_p guarded branch (or block) the
corresponding variable is really constant is just too common.
I think either not threading if b_c_p appears there, or folding it to 0
during the threading is what we want.

	Jakub



More information about the Gcc-patches mailing list