On Sun, Apr 18, 2021 at 4:40 AM Andrew MacLeod via Gcc-patches <gcc-patches@gcc.gnu.org> wrote: > > The code presented at the time wrestrict was invoking ranger has a basic > block with about 7200 statements, all of them calculations which fed > into 2614 logical ORs and 1480 logical ANDs. > > the GORI component which calculates outgoing ranges starts at the exit > of the block and works it way back thru the basic block to the ssa_name > requested, solving the equations along the way. > > Logical expressions require a TRUE and FALSE results to be calculated > for the ssa_name for each of two condition register operands on the > logical expression. Sometimes we can shortcut it, but frequently it its > requires all 4 to properly evaluate. > > When logical operations feed each other, this can become exponential.. > and that was the situation here. > > We had introduced a logical cache to attempt to reduce the number of > calculations, but it was insufficient. We had previously discussed > among ourselves that limiting the depth was probably suifficient, since > the odds of being able to extract a meaningful range thru a large series > of logical operations becomes highly unlikely. > > THis patch implements the depth limiter for logical statements and sets > it at 6. so more than 6 logical statements feeding each other, and we > decide its not worth looking back any further and say this edge does not > compute a range. > > This passes bootstrap and regression testing on x86_64-pc-linux-gnu. I > also ran it against the unlimited depth version on a full set of GCC > source files, and there was 0 difference between this and the original. > > I also disable the logical cache since it isn't really doing anything > any more. > > OK for trunk?
Please make +#define LOGICAL_LIMIT 6 a --param (params.opt, documented in invoke.texi) OK with that change. Thanks, Richard. > > Andrew > > > PS. first mail from a new mailer system... hopefully it formats ok...... > >
