This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [patch tree-optimization]: [3 of 3]: Boolify compares & more
2011/7/8 Michael Matz <matz@suse.de>:
> Hi,
>
> On Fri, 8 Jul 2011, Kai Tietz wrote:
>
>> This is the reworked patch, It fixes vrp to handle bitwise one-bit
>> precision typed operations and to handle some type hoisting cases, Some
>> cases can't be handled as long as vrp doesn't allows to insert new
>> statements in folding pass. To have in first pass better match, VRP uses
>> for stmt-folding now for each BB first -> last stepping. ?I extended for
>> this function substitute_and_fold function by an new argument, which
>> indicates if scanning within BB shall be done from first to last, or
>> from last to first. I removed in this new patch the part of re-doing
>> stmt-fold pass, as this is no longer necessary by changing folding
>> direction within BB.
>
> You still add BIT_IOR_EXPR for POINTER_TYPE_P, which seems strange.
Yes, I am aware of that. I added old behavior for BIT_IOR_EXPR here as otherwise
it would run into the gcc_unreachable case. As here we want to say
varying ... Well, even this
is not necessarily true. As an bitwise-binary-op with different width
on both arguments sides might
still have a smaller range then the type itself.
Eg: x[0..255] | y[0..1024] has a limitted range in result of max.
As we handle here value-ranges and not bit-masks for VR-inspection,
there are some limitations, too.
Eg: (x[mask:0xf0] | y[mask:0x7]) & 8 is for sure zero.
> ?All
> these test for TYPE_PRECISION being 1 (and then handling BIT_IOR/AND_EXPR
> like TRUTH_IOR/AND_EXPR) aren't necessary if you extend the general
> handling for BIT_IOR_EXPR (for instance) to deal with not only constant
> 1, but simply handling all-ones constants specially. ?That is replace
> integer_onep with integer_all_onesp at certain places.
Well, in some cases this is true, but checking for precision has the
advantages that signed cases are covered here and we need not to
compare range min/max. Nevertheless some assumptions on combinations
are only true for one-bit precision types.
> Because also for wider than 1-bit precision it's the case that we can
> infer usefull ranges out of "VARYING | all-ones".
Yes, this might have advantages on some inspections.
Kai