This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH 2/3] Simplify wrapped binops
- From: Robin Dapp <rdapp at linux dot vnet dot ibm dot com>
- To: "Bin.Cheng" <amker dot cheng at gmail dot com>
- Cc: Richard Biener <richard dot guenther at gmail dot com>, GCC Patches <gcc-patches at gcc dot gnu dot org>
- Date: Thu, 18 May 2017 18:08:20 +0200
- Subject: Re: [PATCH 2/3] Simplify wrapped binops
- Authentication-results: sourceware.org; auth=none
- References: <5790A709.4060804@linux.vnet.ibm.com> <6bc1abab-9b54-fb67-fe98-9aaf993859dd@linux.vnet.ibm.com> <CAFiYyc28DaMGuzcMPZQ+AmHXuuNDAyAorMbW0Vo02EEoyZ+xSg@mail.gmail.com> <aba5346a-027f-ee35-0406-3998ab484621@linux.vnet.ibm.com> <CAFiYyc0aExY-MmRczHKJuQ8UFOpMy_+dzV-n05UJJOhuZVywTg@mail.gmail.com> <CAFiYyc0gnMe7j+DgTeudnpH-zD22nK7Cuv4a2zj4Va-anApTBA@mail.gmail.com> <27be603c-4499-ca96-f252-40934d3e420d@linux.vnet.ibm.com> <CAFiYyc1s699beSC9bpDGxY_2ppenDLoP3nbjYSnThF1cp2YHDA@mail.gmail.com> <d6e24bfd-fc3e-4160-fe27-db3eda5b857c@linux.vnet.ibm.com> <CAFiYyc1AcFG8JzoO3LYW9iyGsPj+7Kv17weZp+U3vTaeiqdhKA@mail.gmail.com> <260c4925-29e2-d50a-871e-397e2f9f4efb@linux.vnet.ibm.com> <CAFiYyc2_WX+3vzX27iRO9byK4zoc8N43F-d=Cg2xXoHwLRTgGQ@mail.gmail.com> <CAHFci299r3v3jbaZn0pzKPmk+yvF=Hwnbq+hxYGJCz-y8Qx0jg@mail.gmail.com> <803f5629-2a68-db02-a3a1-16fbe656f242@linux.vnet.ibm.com> <CAHFci2-zFEjPa4TokPca8EDF4zM5PU+0B8maFKa189=Pyrcj7Q@mail.gmail.com>
> Any reason to expose tree-vrp.c internal interface here? The function
> looks quite expensive. Overflow check can be done by get_range_info
> and simple wi::cmp calls. Existing code like in
> tree-ssa-loop-niters.c already does that. Also could you avoid using
> comma expressions in condition please? It only makes the code harder
> to be read.
I tried get_range_info () as well and got a FAIL in
gcc.c-torture/execute/bitfld-5.c.
where get_range_info () returns a VR_RANGE but extract...() gives
VR_VARYING. The test case relies on not simplifying, i.e. would expect
a VR_VARYING here but I didn't look into it more.
Also, is there a possibility to know if there was an "ok" overflow or
not from get_range_info ()'s output? Would I have to compare the result
with the involved variable's range?
Regards
Robin