On Mon, May 16, 2011 at 3:17 PM, Michael Matz <m...@suse.de> wrote: > Hi, > > On Mon, 16 May 2011, Richard Guenther wrote: > >> We can't use a test for BOOLEAN_TYPE as the middle-end considers a >> INTEGER_TYPE with same precision/signedness as compatible and thus may >> propagate a variable of INTEGER_TYPE there. I don't understand why >> promoting bools to boolean_type_node during gimplification does not work >> (it might be slightly undesirable as it might introduce conversions from >> one boolean type to another). >> >> So, to relax the above check to allow any of the boolean types we'd need >> a way to enumerate them. Or make conversions to/from BOOLEAN_TYPEs not >> useless. > > I think conversion _to_ BOOLEAN_TYPE shouldn't be useless, on the grounds > that it requires booleanization (at least conceptually), i.e. conversion > to a set of two values (no matter the precision or size) based on the > outcome of comparing the RHS value with false_pre_image(TREE_TYPE(RHS)). > > Conversion _from_ BOOLEAN_TYPE can be regarded as useless, as the > conversions from false or true into false_pre_image or true_pre_image > always is simply an embedding of 0 or 1/-1 (depending on target type > signedness). And if the BOOLEAN_TYPE and the LHS have same signedness the > bit representation of boolean_true_type is (or should be) the same as the > one converted to LHS (namely either 1 or -1).
Sure, that would probably be enough to prevent non-BOOLEAN_TYPEs be used where BOOLEAN_TYPE nodes were used before. It still will cause an artificial conversion from a single-bit bitfield read to a bool. Richard. > > Ciao, > Michael. >
