This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Project Ranger
- From: Eric Botcazou <ebotcazou at adacore dot com>
- To: Andrew MacLeod <amacleod at redhat dot com>
- Cc: gcc at gcc dot gnu dot org, Aldy Hernandez <aldyh at redhat dot com>, Jeff Law <law at redhat dot com>
- Date: Fri, 01 Jun 2018 10:15:54 +0200
- Subject: Re: Project Ranger
- References: <5607b582-639b-7517-e052-014fabfe0ad4@redhat.com> <1946549.HoKu4gN0qI@polaris> <23520229-0872-f990-9273-f0c0c61635f4@redhat.com>
> First, we'll collect the cases that demonstrate a unique situation we
> care about. I have 4 very specific case that show current
> shortcomings.. Not just with the Ranger, but a couple we don't handle
> with VRP today. .. I'll eventually get those put onto the wiki so the
> list can be updated.
I'm not specifically worried here, there is already a couple of testcases in
the testsuite that require symbolic information to be properly optimized.
> I think most of these cases that care about symbolics are not so much
> range related, but rather an algorithmic layer on top. Any follow on
> optimization to either enhance or replace vrp or anything similar will
> simply use the ranger as a client. If it turns out there are cases
> where we *have* to remember the end point of a range as a symbolic, then
> the algorithm to track that symbolic along with the range, and request a
> re-evaluation of the range when the value of that symbolic is changes.
>
> [...]
>
> Does that help? If it does, I'll add this to the coverage in the wiki
> page.
Yes, thanks for the detailed explanation. This approach of setting aside the
handling of symbolic information might end up being a good compromise between
the necessary minimal[*] handling of this information and the complexity of
doing it directly in the Ranger.
[*] The implicit assumption hee is that a VRP implementation with full-blown
support of symbolic ranges is not worth the hassle in practice.
--
Eric Botcazou