This is the mail archive of the
mailing list for the GCC project.
Re: fold() can't fold simple expressions?
On Wed, Sep 14, 2016 at 3:35 PM, Aldy Hernandez <firstname.lastname@example.org> wrote:
> On 09/14/2016 09:32 AM, Jakub Jelinek wrote:
>> On Wed, Sep 14, 2016 at 09:25:30AM -0400, Aldy Hernandez wrote:
>>> Hi folks. I'm working on better range information with Macleod, and I've
>>> been playing with folding arbitrary range expressions, which I expect
>>> to ahem...fold.
>>> I'm surprised that even seemingly simple trees can't be folded after
>>> been built, because AFAICT, fold actually just works by recognizing
>>> it recognizes at the top level, not by recursing down to the sub-trees.
>> Yes, that is how fold is designed.
>>> For example, I was surprised at this:
>>> #define INT(N) build_int_cst (integer_type_node, (N))
>>> tree x = build2 (PLUS_EXPR, integer_type_node,
>>> build2 (MULT_EXPR, integer_type_node, INT(20), INT(3)),
>> You should be folding it when building it, i.e. fold_build2 in both cases.
>> In the FEs where we don't want to fold everything immediately, we then
>> c_fully_fold and cp_fully_fold that fold things recursively.
>> So, the question is why do you want to fold recursively in the middle-end,
>> instead of folding when building the expressions.
> Well, I can use fold_buildN to build it, but I'll be folding something like
> "20 * ssa_38 + 10" which fold() can't do anything about. It's only at a
> later time that I'll substitute ssa_38 <== 3. At which point, I basically
> need to refold everything, no?
You only need to re-fold affected expressions, but yes. Btw, in your refold ()
please try to optimize unchanged tails to be re-used rather than re-constructed
via fold_buildN ().