Hi, On Mon, 11 Feb 2013, Paulo Matos wrote:
> The following self-contained md file generates an infinite loop in genattrtab: > (define_attr "fpsize" "short,long" (const_string "short")) > > (define_attr "fplength" "" > (if_then_else > (eq_attr "fpsize" "long") > (const_int 8) > (const_int 4))) > > (define_insn "br_pred" > [(set (pc) > (if_then_else > (match_operator 2 "easy_comparison" > [(match_operand:BI 0 "register_operand" "c") > (const_int 0)]) > (label_ref (match_operand 1 "" "")) > (pc)))] > "" > "brtest" > [(set (attr "fplength") (const_int 4)) > (set (attr "fpsize") > (if_then_else (eq_attr "fplength" "4") (const_string "short") > (const_string "long")) > ) > ]) > > > The infinite loop occurs in genattrtab.c:get_attr_order. The loop inside > get_attr_order never exits. It seems to be a topological sort, and since > fpsize depends on fplength and vice-versa, it keeps looping. The strange > thing is that when genattrtab looks at all the attributes and > instructions, it accumulates all possible values for each attribute, so > the list of attribute values for fpsize and fplength are indeed > dependent on each other even though in the context of br_pred, they are > not inter-dependent because we fixed the value of fplength at 4, so > calculating the value of fpsize should be straightforward. > > It feels like this could be improved. Do you agree? Only by giving a nicer error message than an infinite loop. Attributes may not depend cyclically on each other. You are right that in this specific case for this one instruction genattrtab could find out something working itself, because there a seeding value that's computable by genattrtab. But that's not how it works. The disallowance of cyclic dependencies was always implicitely there (and adhered to by all in-tree ports), but was made explicit when improving genattrtab's runtime behaviour and its generated code quality. Ciao, Michael.
