From: Andrew MacLeod <amacleod@redhat.com>
To: Richard Biener <richard.guenther@gmail.com>
Cc: Jeff Law <law@redhat.com>, Aldy Hernandez <aldyh@redhat.com>,
gcc-patches <gcc-patches@gcc.gnu.org>
Subject: Re: [range-ops] patch 01/04: types for VR_UNDEFINED and VR_VARYING
Date: Thu, 01 Aug 2019 16:35:00 -0000 [thread overview]
Message-ID: <0afb589c-d0e8-4775-5d79-e5e9e57c42dd@redhat.com> (raw)
In-Reply-To: <CAFiYyc2U+MrkG-RSc53D=VG_5Uii_GhhN10c8q7rdNVuatCsvA@mail.gmail.com>
On 8/1/19 10:11 AM, Richard Biener wrote:
> On Thu, Aug 1, 2019 at 1:24 AM Andrew MacLeod <amacleod@redhat.com> wrote:
>
>> Aldy started this relatively straightforward submission a month ago (!!
>> July 1st!), and we've made virtually no progress since then.
> Actually I think it's a waste of time on my side since I actually sat
> down and looked at the branch - because while you posted several
> "merge plans / proposals" the actual patches you proposed for integration
> were just changes to the existing code. But then when I tried to
They are preliminary patches which enable us to align irange and
value_range so they can be used interchangeably as the range class
everywhere. We've adjusted irange on the branch to align with
value_range, and these tweaks to the value_range API make them fully
interchangeable.
So yes, this first set of patches are just changes to the existing
code... We need them before we can bring in range-ops.  After that
comes the outgoing range computational component, but I'm worried we're
short on time for that now :-(Â we'll see.
> understand why you need those by looking at the branch (OK, criticizing
> some stuff I saw there) you said "well, don't look - it's all just a prototype
> and even the APIs are not finished".
I explained numerous times why we needed the changes, you appear to
simply not believe me. There should not have been a need to look at
unprepared code.
As for being not finished, the API is being tweaked for trunk.. 2 things
in particular:
 1) I'm adding a type to the calls since we won't have a type for
undefined any more. The aggregation of sub-ranges always started with
undefined and built up from there, and it can no longer find the type
from undefined.
 2) The Implementation of each operation was still using chains of
calls into legacy code which often used big switches... I'm collapsing
those into a basic operation call on wide-ints which is being added to
the API.   This will dramatically change the look of the file, without
changing its basic behaviour.
So its virtually the same code, but with a very different (and cleaner)
look designed for trunk... we didn't really care what it looked like on
the branch, we just wanted functionality... and it shows. Hence my
desire to not have it critiqued :-)Â The intention was always to rework
it for trunk before having it examined.
I'll also modify the entire file to use value_range instead of irange.Â
We don't want to contaminate trunk with pointless #defines or other
silliness. We'll manage irange compatibility for range-ops on the
branch. The varying min/max change we were trying to get in is a hard
prerequisite for value_range to function properly in this role.
> That makes me wonder why you do changes to trunk or proposing
> merge plans when you've not even finished designing stuff...
>
> As said, I feel I am wasting my time here so please feel free to
> do whatever you are up to with VRP.
>
> I did help with considerable resources even during last stage1/3 with
> "fixing" the half-way conversion of value_range to a class. I've not
> manged to beat sense into the wide-int-range.h API, but oh well.
yes, and I really do appreciate that work, it was critical to paving the
way to allowing us to use value_range instead of irange... We just need
these final couple of things to finish that transition, and they were
just not happening, thus my reaction.
I think the new range-op operation on wide-ints that is being added to
the API will probably replace most, if not all, of the wide-int-range.h
stuff... We'll see how it goes when I finally get back to finishing it.
Anyway, I'm off after today for a week, so we wont do anything further
until I get back.
The weekend will be here shortly... Have a good one.
Andrew
next prev parent reply other threads:[~2019-08-01 16:35 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-07-01 8:52 Aldy Hernandez
2019-07-02 20:17 ` Jeff Law
2019-07-03 9:46 ` Aldy Hernandez
2019-07-03 22:40 ` Jeff Law
2019-07-03 8:28 ` Richard Biener
2019-07-03 9:19 ` Aldy Hernandez
2019-07-03 11:08 ` Richard Biener
2019-07-03 12:23 ` Aldy Hernandez
2019-07-03 12:30 ` Aldy Hernandez
2019-07-04 10:34 ` Richard Biener
2019-07-09 7:49 ` Aldy Hernandez
2019-07-09 9:57 ` Richard Biener
2019-07-16 19:56 ` Andrew MacLeod
2019-07-22 15:38 ` Aldy Hernandez
2019-07-23 0:19 ` Jeff Law
2019-07-23 9:45 ` Richard Biener
2019-07-24 16:09 ` Jeff Law
2019-07-24 17:06 ` Richard Biener
2019-07-24 18:33 ` Jeff Law
2019-07-24 18:38 ` Richard Biener
2019-07-26 3:41 ` Jeff Law
2019-07-26 14:52 ` Andrew MacLeod
2019-07-30 9:02 ` Richard Biener
2019-07-30 15:16 ` Andrew MacLeod
2019-07-31 8:37 ` Richard Biener
[not found] ` <78846d0a-354e-b73a-6e15-123752038fb2@redhat.com>
2019-08-01 14:11 ` Richard Biener
2019-08-01 16:35 ` Andrew MacLeod [this message]
2019-07-26 4:34 ` Jeff Law
2019-07-24 20:52 ` Andrew MacLeod
2019-07-25 9:13 ` Richard Biener
2019-07-23 9:34 ` Richard Biener
2019-07-23 23:05 ` Andrew MacLeod
2019-07-24 13:28 ` Richard Biener
2019-07-24 18:07 ` Andrew MacLeod
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=0afb589c-d0e8-4775-5d79-e5e9e57c42dd@redhat.com \
--to=amacleod@redhat.com \
--cc=aldyh@redhat.com \
--cc=gcc-patches@gcc.gnu.org \
--cc=law@redhat.com \
--cc=richard.guenther@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).