On Wed, Sep 14, 2016 at 3:35 PM, Aldy Hernandez <al...@redhat.com> 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 >>> fold() >>> to ahem...fold. >>> >>> I'm surprised that even seemingly simple trees can't be folded after >>> they've >>> been built, because AFAICT, fold actually just works by recognizing >>> patterns >>> 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)), >>> INT(10)); >> >> >> 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 >> have >> 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 (). Richard. > Aldy
