This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Great example of why "everything is a tree" sucks
- From: Richard Biener <richard dot guenther at gmail dot com>
- To: Jeff Law <law at redhat dot com>
- Cc: Jakub Jelinek <jakub at redhat dot com>, GCC <gcc at gcc dot gnu dot org>
- Date: Wed, 13 Nov 2013 11:15:45 +0100
- Subject: Re: Great example of why "everything is a tree" sucks
- Authentication-results: sourceware.org; auth=none
- References: <528288B3 dot 8010109 at redhat dot com> <20131112203509 dot GC27813 at tucnak dot zalov dot cz> <52829CB1 dot 4070006 at redhat dot com>
On Tue, Nov 12, 2013 at 10:25 PM, Jeff Law <law@redhat.com> wrote:
> On 11/12/13 13:35, Jakub Jelinek wrote:
>>
>> On Tue, Nov 12, 2013 at 12:59:47PM -0700, Jeff Law wrote:
>>>
>>> So I lost something like 3 hrs last night due to writing a hunk of
>>> code like this
>>>
>>> if (INTEGRAL_TYPE_P (gimple_assign_lhs (stmt)))
>>
>>
>> INTEGRAL_TYPE_P is a macro, which accepts everything, just adding
>> a TYPE_CHECK to that macro would be sufficient to catch that
>
> Yes, I know full well that I could hack up INTEGRAL_TYPE_P to detect this
> case and my brain damage would have been caught via the check sometime
> during building the runtime libraries or the stage2 build.
>
> My point is the mere need to hack up INTEGRAL_TYPE_P in that way is a result
> of a fundamental misdesign of the tree structures. If the structures were
> properly designed what I did would have been flagged as a compile error.
>
> It's that fundamental mis-design that we're trying to correct now with the
> work from Andrew, David & others.
You know - 'tree's were a design decision (well, just my guess - I wasn't
around 25 years ago ...). They are a perfect match to represent an AST.
So I'd say whoever introduced that middle-end between the FEs AST
and RTL was at fault :P (luckily I wasn't around either ... ;))
Still splitting 'tree's into a few separate classes is not hard. It's just
work - and in the end even the frontends will benefit. Oh, and I believe
it is a project that has a much higher success rate than trying to
replace trees with "something else" in the GIMPLE and RTL middle-end
only and have that cooperate sanely with the rest of the compiler.
Something along 1 man year for the first with a 75% success chance
against 6 man years for the second with a 20% success chance.
And the nice thing is that the first can be done incrementally
(we _are_ already in the process of that transition - see the changes
done to 'tree' during the last 6 years). And the other nice thing is that
even non-100% success will end up in something better than we have now.
With the second project it's a all-or-nothing (or rather
all-or-just-uglification).
Richard.
> Jeff
>