This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Some thoughts and quetsions about the data flow infrastracture
> Actually, simplify-rtx.c now uses nonzero_bits and num_sign_bit_copies:
> these ask combine for the value in the case of pseudos, via the "RTL
> hooks" mechanism.
Right. That was certainly a step (and was discussed a while ago), but doing
it more globally would make it even easier.
> 1) what to do with (clobber (const_int 0)). This should be not so much
> of a problem thanks to validate_change, but I'd be weary of having such
> CLOBBER rtx-en in REG_EQUAL notes!
Just return NULL. The philosophy of simplify_rtx is different from combine.
In the former, you're being asked "can you simplify this?" while in the
latter, there's a lot of intertwining between simplification and
substitution. So you can just return "no, I can't simplify it" and combine
would then do what it wants do with that result.
> 2) a lot of this is hard to be done incrementally. For example, it is
> hard to move any one of simplify_and_const_int, make_compound_operation,
> expand_compound_operation, force_to_mode, simplify_shift_const without
> moving the others.
Indeed. And you can't just move them intact because of the change of
philosphy. I originally wrote those routines and so am the most familiar
with them. Once the infrastructure is ready, I probably should take a look
at what's involved.
> > That means we could merge CSE and combine and do a *lot* more than we ever
> > were able to do before while having the code for both passes be much
> > simpler.
>
> Unfortunately, we should not forget CSE's secondary functionality, which
> is to act as garbageman for the GCSE pass.
Right, but much of that functionality is more in the arena of operand selection
than true "cse".