"Matt Lee" <reachmatt.lee@xxxxxxxxx> writes: > Thanks again. I do agree that my costs calculation do not recurse into > the sub-expressions, but I was just mimicing other ports in this > regard (see rs6000 for instance) . They do not recurse into > sub-expressions as well. In the current mainline, the costs calculation in rs6000.c returns false for AND and friends. I haven't looked at the 3.4 sources (I don't have them checked out). > Also, I think I traced the problem to fold-const.c::fold_single_bit_test() > > /* If we have (A & C) != 0 or (A & C) == 0 and C is a power of > 2, then fold the expression into shifts and logical operations. */ > tem = fold_single_bit_test (code, arg0, arg1, type); > if (tem) > return tem; You're right, it looks like this is fixed in 4.1 and current mainline with the patch in PR 14846. > On a related note, it looks the if-conversion phase as well, chooses > to use a bunch of shifts and other logical operations to convert a > branch into linear code. This is fine, except that the resultant > operations prove more expensive than a branch. I will take a closer > look at the IFCVT_* macros and see if one of them is useful for > catching these conditions. If-conversion also uses costs to make these determinations. The thing to tweak is BRANCH_COST, and perhaps MAX_CONDITIONAL_EXECUTE. Hope this helps. Ian
