Folks. I have decided to put this aside until the next release. I
originally wanted a simple rename, and reimplementing things to align
with rtl, etc, is beyond what I want to tackle on this late.
I'll archive this away, and revisit it when we implement the
irange::known_ones mask.
Thanks for y
On Fri, Oct 21, 2022 at 3:15 PM Aldy Hernandez via Gcc-patches
wrote:
>
> The name nonzero_bits is confusing. We're not tracking nonzero bits.
> We're tracking known-zero bits, or at the worst we're tracking "maye
> nonzero bits". But really, the only thing we're sure about in the
> "nonzero" bi
On Fri, Oct 21, 2022 at 06:54:32PM +0200, Jakub Jelinek wrote:
> On Fri, Oct 21, 2022 at 06:51:19PM +0200, Jakub Jelinek wrote:
> > Agreed.
> >
> > I think maybe_nonzero_bits would be fine.
>
> Or yet another option is to change what we track and instead of
> having just one bitmask have 2 as tre
On Fri, Oct 21, 2022 at 06:51:17PM +0200, Jakub Jelinek wrote:
> On Fri, Oct 21, 2022 at 11:45:33AM -0500, Segher Boessenkool wrote:
> > On Fri, Oct 21, 2022 at 03:14:26PM +0200, Aldy Hernandez via Gcc-patches
> > wrote:
> > > * asan.cc (handle_builtin_alloca): Rename *nonzero* to *known_zero*.
On Fri, Oct 21, 2022 at 06:51:19PM +0200, Jakub Jelinek wrote:
> Agreed.
>
> I think maybe_nonzero_bits would be fine.
Or yet another option is to change what we track and instead of
having just one bitmask have 2 as tree-ssa-ccp.cc does,
one bitmask says which bits are known to be always the sam
On Fri, Oct 21, 2022 at 11:45:33AM -0500, Segher Boessenkool wrote:
> On Fri, Oct 21, 2022 at 03:14:26PM +0200, Aldy Hernandez via Gcc-patches
> wrote:
> > The name nonzero_bits is confusing. We're not tracking nonzero bits.
> > We're tracking known-zero bits, or at the worst we're tracking "maye
Hi!
On Fri, Oct 21, 2022 at 03:14:26PM +0200, Aldy Hernandez via Gcc-patches wrote:
> The name nonzero_bits is confusing. We're not tracking nonzero bits.
> We're tracking known-zero bits, or at the worst we're tracking "maye
> nonzero bits". But really, the only thing we're sure about in the
>
The name nonzero_bits is confusing. We're not tracking nonzero bits.
We're tracking known-zero bits, or at the worst we're tracking "maye
nonzero bits". But really, the only thing we're sure about in the
"nonzero" bits are the bits that are zero, which are known to be 0.
We're not tracking nonzer
