https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94779
Martin Liška changed:
What|Removed |Added
Status|ASSIGNED|NEW
Assignee|marxin at gcc dot
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94779
--- Comment #22 from Andrew Macleod ---
(In reply to Martin Liška from comment #21)
> > See my comment above. It isn't any integration of VRP, just asking the
> > ranger about the range, and it isn't useless because to be able to optimize
> > pr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94779
--- Comment #21 from Martin Liška ---
> See my comment above. It isn't any integration of VRP, just asking the
> ranger about the range, and it isn't useless because to be able to optimize
> properly,
> you need to figure out for each value one
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94779
--- Comment #20 from Jakub Jelinek ---
(In reply to Martin Liška from comment #19)
> >
> > One of the work items for the next release is to multi-range enable all
> > these consumers that can make use of the information.
>
> I would really appr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94779
--- Comment #19 from Martin Liška ---
>
> One of the work items for the next release is to multi-range enable all
> these consumers that can make use of the information.
I would really appreciate that. I'm don't like integrating VRP into the CS
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94779
--- Comment #18 from Andrew Macleod ---
(In reply to Jakub Jelinek from comment #17)
> (In reply to Martin Liška from comment #16)
> >
> > EVRP knows the proper range:
> > 2->4 (F) x_6(D) : unsigned int [0, 1][4, 4]
>
> EVRP ATM invokes both
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94779
--- Comment #17 from Jakub Jelinek ---
(In reply to Martin Liška from comment #16)
> > The old VRP/EVRP only tracks simple ranges and anti-ranges, so can't deal
> > with
> > what you have above, the new ranger code can deal with multiple subrange
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94779
--- Comment #16 from Martin Liška ---
(In reply to Jakub Jelinek from comment #15)
> (In reply to Martin Liška from comment #14)
> > Ok, I've just taken look at what EVRP pass does before SWITCHCONV pass is
> > called.
> > I see that EVRP can pro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94779
--- Comment #15 from Jakub Jelinek ---
(In reply to Martin Liška from comment #14)
> Ok, I've just taken look at what EVRP pass does before SWITCHCONV pass is
> called.
> I see that EVRP can properly prune dead cases of a switch, but it's not
> p
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94779
--- Comment #14 from Martin Liška ---
(In reply to Jakub Jelinek from comment #12)
> So, for start I think we should do:
> 1) query->range_of_expr (m_index_range, m_index_expr, swtch)
>where query is address of gimple_ranger passed down from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94779
--- Comment #13 from Andrew Macleod ---
(In reply to Jakub Jelinek from comment #12)
> So, for start I think we should do:
> 1) query->range_of_expr (m_index_range, m_index_expr, swtch)
>where query is address of gimple_ranger passed down fro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94779
Jakub Jelinek changed:
What|Removed |Added
CC||amacleod at redhat dot com
--- Comment #
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94779
--- Comment #11 from Jakub Jelinek ---
Related PR is PR89059 though, while we can have a useful range info already in
the early opts from evrp, in many cases we can get much better info after
inlining. So, if we during the first switchconv pass
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94779
Martin Liška changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |marxin at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94779
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94779
--- Comment #8 from Gabriel Ravier ---
Also, this code :
int f1(unsigned x)
{
if (x >= 3)
__builtin_unreachable();
switch (x)
{
case 0:
return 1;
case 1:
return 2;
case 2:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94779
Richard Biener changed:
What|Removed |Added
Status|REOPENED|NEW
--- Comment #7 from Richard Biener
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94779
--- Comment #6 from Gabriel Ravier ---
There is another thing I realised : This code :
int f1(unsigned x)
{
switch (x)
{
case 0:
return 1;
case 1:
return 2;
case 2:
return 3;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94779
--- Comment #5 from Gabriel Ravier ---
Going to take a quick look at how it gets optimized in the tree passes.
This is the first case :
int f1(unsigned x)
{
if (x >= 2)
__builtin_unreachable();
switch (x)
{
case 0:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94779
Martin Liška changed:
What|Removed |Added
Keywords||missed-optimization
Status|RE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94779
--- Comment #3 from Gabriel Ravier ---
Just fyi : When I said "gcc fails to optimize this to `return x + 1`, instead
opting for some rather weird code generation (involving `sbb` on x86)" the
"weird code generation" I was referring to is the exac
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94779
--- Comment #2 from Gabriel Ravier ---
It's fully optimized ? I don't see how. This is exactly what I was complaining
about : It could be further optimized to
leal1(%rdi), %eax
ret
but it isn't
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94779
Martin Liška changed:
What|Removed |Added
Resolution|--- |INVALID
CC|
23 matches
Mail list logo
