This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Project Ranger


> 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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]