This is the mail archive of the gcc-patches@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: [range-ops] patch 01/04: types for VR_UNDEFINED and VR_VARYING


On Thu, Aug 1, 2019 at 1:24 AM Andrew MacLeod <amacleod@redhat.com> wrote:
>
> On 7/31/19 4:36 AM, Richard Biener wrote:
> > On Tue, Jul 30, 2019 at 4:54 PM Andrew MacLeod <amacleod@redhat.com> wrote:
> >> Everything in this compiler is historical. We did everything we could to
> >> save memory back in the old days, I know, I was there when we did this.
> >>     Combining the lattice and the range made sense in that context.  In
> >> fact, you could get rid of the lattice structure entirely with the way
> >> we represent irange... we have varying and undefined values query-able
> >> from the range without anything special.  That seems even more efficient
> >> to me, and that's the way I'd implement it today... no artificial
> >> lattice overlay needed, just the range.
> >>
> >> Lattices will eventually go away. I personally don't see any point in us
> >> spinning our wheels re-implementing them when they are slated to be
> >> removed. Until then, there is absolutely nothing wrong with the way it
> >> works right now.  Adding the min and max to the varying node has no
> >> impact on how lattices work, it just allows value_range to interact with
> >> new range code better..
> >>
> >> This change is trivial. it actually fixes a few warts. It lets us move
> >> on with other more significant things.
> >>
> >> I've been trying to play nice and get agreement, but after a week and a
> >> half it seems like that isn't going to happen. I welcome any further
> >> comments on the patch, but otherwise I will approve the patch.
> >>
> >> I will note this is the first time in a very long time that I have had
> >> to exercise my maintainer authority as one of the original architects of
> >> tree-ssa. I have been content to let others review and arrive at a
> >> consensus, but the system is not working this time. Its unclear to me
> >> why you are being so insistent about this trivial matter.  I will
> >> continue to make approvals as necessary going forward, but I still
> >> welcome your input and would prefer to settle on agreement to future
> >> patches.
> > Fair enough - have fun.
> >
> > Richard.
> >
>
> In summary, We don't want to do it your way so you wash your hands of it
> and assign all VRP bugs to me stating I am now VRP maintainer.

I didn't assing them, I unassigned them from myself and CCed you.
Three bugs it was I think.

> 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
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".

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.

>You weren't
> holding us up on technical merits, it appeared to be a personal
> preference to not do things our way, despite the explanations and
> cleanups it provided.   I felt I had no choice but to move forward or we
> will not get any code in before stage 1 ends. We're already a month
> behind now, and with vacations looming I fear our initial goals are
> already in serious danger.  Our code certainly won't be in for as long
> as I would have liked.   I still don't know why you were so insistent it
> had to be all your way...    We made a lot of effort to accommodate you
> out of respect for what you do for GCC, it would have been nice to see a
> little in return.
>
> Regardless, you have knowledge in this space which is useful, and we
> welcome your input along the way should you decide to provide it.
>
> Now, on to trying to improve ranges and VRP.

And I'm on doing non-VRP stuff now.  There's other capable reviewers
that will help you out.

Richard.

> Andrew
>
>
>


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