https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55157
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |13.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55157
Aldy Hernandez changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55157
--- Comment #13 from CVS Commits ---
The master branch has been updated by Aldy Hernandez :
https://gcc.gnu.org/g:a239a63f868e29e9276088e7c0fb00804c2903ba
commit r13-3761-ga239a63f868e29e9276088e7c0fb00804c2903ba
Author: Aldy Hernandez
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55157
--- Comment #12 from Aldy Hernandez ---
Created attachment 53831
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53831&action=edit
solution improving MULT_EXPR range-ops
Another solution is just improving the MULT_EXPR range-op entry. This
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55157
Aldy Hernandez changed:
What|Removed |Added
Attachment #53826|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55157
--- Comment #10 from Aldy Hernandez ---
Original TYPE_UNSIGNED patch with leading / trailing suggestions: -2.52%
As attached: -3.62%
Moving the code out of set_range_from_nonzero_bits back into set_nonzero_bits:
-3.7%
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55157
--- Comment #9 from Aldy Hernandez ---
(In reply to Aldy Hernandez from comment #7)
> (In reply to Andrew Macleod from comment #6)
> > (In reply to Aldy Hernandez from comment #4)
> > 3) It also seems to me that you then only need to add the zer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55157
--- Comment #8 from Aldy Hernandez ---
Created attachment 53826
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53826&action=edit
untested
Here's what I tested and we're still around a 3% degradation for VRP.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55157
--- Comment #7 from Aldy Hernandez ---
(In reply to Andrew Macleod from comment #6)
> (In reply to Aldy Hernandez from comment #4)
>
> >
> > The patch below does this, but it does have a 3% penalty for VRP (though no
> > penalty to overall comp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55157
--- Comment #6 from Andrew Macleod ---
(In reply to Aldy Hernandez from comment #4)
>
> The patch below does this, but it does have a 3% penalty for VRP (though no
> penalty to overall compilation). I'm inclined to pursue this route, since
> i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55157
--- Comment #5 from Aldy Hernandez ---
(In reply to Aldy Hernandez from comment #4)
> + // Reflect the mask as a simple range. For example, a mask of
> + // 0xff00 could be represented as [0,0][0x100, 0x].
> + if (TYPE_UNSIGNED (type ())
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55157
Aldy Hernandez changed:
What|Removed |Added
CC||aldyh at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55157
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed|2021-06-08 00:00:00 |2021-12-25
--- Comment #3 from Andrew Pi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55157
--- Comment #2 from Marc Glisse ---
Instead of looking at the definition, it could also look at get_nonzero_bits.
It would help when being a multiple of 16 is less obvious, but it wouldn't do
anything useful for t*15. It might be easier to optimi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55157
Andrew Pinski changed:
What|Removed |Added
Keywords||missed-optimization
Status|U
15 matches
Mail list logo
